RE: What is personal identifiable data - in your country?

["Scott Cantor" <cantor.2@xxxxxxx>]

> My opinion here is that the wrong attributes are being sent if you cant
> easily explain them to the user. After all, these are the user's PII. So
> he/she should be able to understand what is being asserted about
> him/her.  (And I am not talking about the name that is sent in the
> protocol, like eduPersonXXXX which is meaningless to the user, but about
> the semantics of the attribute that should be able to be explained
> easily, such as "your degree subject, your department, your unique
> computer assigned ID" etc.

No, I don't mean the internal names, but I think some forms of PII are very
difficult to explain. Various kinds of identifiers have profound differences
in privacy outcomes that users simply don't understand (and it gets worse
when you try and explain how the different types might interact with other
SP-side processes such as was alluded to separately in this thread.

To use one of your examples, I'm not even sure what "unique computer
assigned ID" is, and I guarantee most users wouldn't know what you meant by
it.

That said, the real issue is that I don't think a user can make an informed
decision when it comes to attribute-level blocking because there's no way to
really explain concisely (or even know in most cases) what the implication
of a particular decision will be.

There *are* use cases for dynamic determinations of attribute requirements,
particularly in scenarios where you have to acquire more data after the
initial login. But there are *many* use cases in which the federation can
help play an active role in establishing a reasonable required/optional
attribute set for an SP in its metadata and giving the user a much clearer
"access this or not?" choice that doesn't require a per-attribute decision.

You're advocating a position in which what we can do today across several
protocols is somehow unworkable, and I don't agree with that.
 
> You are going to have a real hard time selling that to everyone (or
> perhaps anyone). I believe this is a non-starter from a trust
> perspective. Why would anyone trust my university to tell anyone my
> postal address or Visa card number? My university is authoritative only
> for university related attributes, and people will trust it for these.

Sites do in fact rely on unusual sources for data when it's convenient to do
so and there are contractual agreements in place to do so. In fact, today in
the attribute workshop that was held in Washington, a lot of discussion
about attribute "assurance" bounced around the idea that non-cryptogaphic
statements about who verified a particular attribute (separate from who's
asserting it) may be sufficient for a lot of use cases.

Some people seem unwilling to accept the idea that the full complexity of
assurance should be applied to attributes in the early stages. That isn't my
position, necessarily, but I do think that it's unrealistic to believe that
most RPs really understand any of these nuances at this point.

> I have used CardSpace a couple of times with web sites, and its
> performance seemed to be acceptable. But I dont like the fact that I
> cant get into my card selector at will to edit or export my cards. It
> seems like I have to be in the middle of talking to an SP before it is
> activated.

Cardspace is a control panel applet, at least on Windows XP, I can get into
it that way.

-- Scott