OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Comment on sstc-saml-glossary-2.0 (also closes AI #0114)


> Agreed, many different identifiers can express federated identity so it is
> not clear what is meant by "7.3.6 Federated Identifier". 
> Perhaps this should be "Persistent Privacy Preserving Identifier" or
> "Persistent Pseudonym" ? 

Roughly yes. I think that's what is relevant there.

> I have no issue with this approach. The only thing somewhat unclear to me
> is how the <AuthNRequest, AuthResponse> pair is used for establishing a
> identity federation for a particular principal. Maybe I just need to read
> section 3.4 carefully.

The chief difference between ID-FF and my proposed protocol is that it does
not contain semantics for creating one. I can tell the IdP that I want a
particular kind of identifier, and persistence is certainly one property of
various kinds we have. It's the IdP that recognizes the relationship it may
have with the requester for that principal, or the IdP can create such a
relationship, subject to policy and consent, etc.

The SP can then participate in or ignore that relationship, but it never
puts anything in an AuthnRequest that distinguishes between an existing one
and a new one. I have not seen a need to make that distinction in the spec.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]