Hi Sam, thanks for the quick response.
On Aug 16, 2012, at 3:22 PM, Sam Hartman wrote: >>>>>> "Hannes" == Hannes Tschofenig <[email protected]> writes: > > Hannes> Privacy: > > Hannes> Often a Relying Party does not need to know the > Hannes> identity of a Subject to reach an access management > Hannes> decision. It is frequently only necessary for the Relying > Hannes> Party know specific attributes about the subject, for > Hannes> example, that the Subject is affiliated with a particular > Hannes> organisation or has a certain role or entitlement. > Hannes> Sometimes the RP does not need to know the identity of the > Hannes> Subject, but does require a unique identifier for the > Hannes> Subject (for example, so that it can recognise the Subject > Hannes> subsequently); in this case, it is a common practise for the > Hannes> IdP to only release a pseudonym that is specific to that > Hannes> particular Relying Party. Federated access management > Hannes> therefore provides various strategies for protecting the > Hannes> Subject's privacy. Other privacy aspects typically of > Hannes> concern are the policy for releasing personal data about the > Hannes> Subject from the IdP to the RP, the purpose of the usage, > Hannes> the retention period of the data, and many more. > > Hannes> This paragraph needs to be re-written to something like: > > Hannes, I'd appreciate it if you would describe your concerns with the > original paragraph. From my standpoint the original paragraph does a > much better job of describing these issues from the ABFAb standpoint. > One particular concern is that I think bringing consent in without a lot > more discussion > may provide an accurate description of our hopes, but not so much of the > realities. The issue with the original paragraph is the following. Privacy: [hannes] The title privacy suggests that we cover privacy as a whole but instead the paragraph only discussed a small area of privacy. For this reason I suggested to change the title of that paragraph Often a Relying Party does not need to know the identity of a Subject to reach an access management decision. It is frequently only necessary for the Relying Party know specific attributes about the subject, for example, that the Subject is affiliated with a particular organisation or has a certain role or entitlement. [hannes] Here we have a terminology issue. Let me copy the definition of "identity" here: http://tools.ietf.org/html/draft-iab-privacy-considerations-02 " $ Identity Any subset of a data subject's attributes that identifies the subject within a given context. Data subjects usually have multiple identities for use in different contexts. " So, I think what the above sentence tries to say is that the relying party only needs to know a (small) subset of the subject's attributes and particularly not an identifier that is persistent across multiple sessions. Sometimes the RP does not need to know the identity of the Subject, but does require a unique identifier for the Subject (for example, so that it can recognise the Subject subsequently); [hannes] This also confused the terminology. A unique identifier of a subject is one of the identities of the subject. in this case, it is a common practise for the IdP to only release a pseudonym that is specific to that particular Relying Party. [hannes] Here is the definition of the pseudonym: " $ Pseudonym An identifier of a data subject other than the subject's real name. " So, I guess the previous sentence should have talked about identifiers rather than identities. Federated access management therefore provides various strategies for protecting the Subject's privacy. Other privacy aspects typically of concern are the policy for releasing personal data about the Subject from the IdP to the RP, the purpose of the usage, the retention period of the data, and many more. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
