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)


> An aditional example:
> 
> (5) The IdP and the SP agree on a handle for the user out-of-band (such
> as an employee number used between an employer and their payroll
> service provider.

Perhaps we should raise the issue of exactly whether and how we need to call
out a specific Format identifier of "federated" in the spec. What does it
mean, if anything? We have NameIdentifier attributes that do most of the
"work", so to speak, of identifying the parties to a federation, assuming
that an identifier needs to be so-scoped at all, and they're usable by an
identifier in any format.

Can we define a set of properties relating to persistence and/or privacy
that we can give a different name to, and open up the rest of the spec
relating to federation to essentially any kind of NameIdentifier?

Can I send a RegisterNameIdentifier message and just say "I used to send you
assertions about foo, format bar and now I'll use bar, format foo and now
you know it's the same guy"? I can't see any particular problem in that.

Any SP is free to treat the NameIdentifier as a blob or to interrogate it
for Format to learn something useful, but the issues of registration and
termination are around the use of the identifier as a shared handle and not
the other aspects that the identifier might or might not have, such as
privacy-preservation.

-- Scott



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