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

["Mishra, Prateek" <pmishra@netegrity.com>]

[Scott]
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.
[\Scott]

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" ? 

Section 7.3.6 would be restricted to explaining how privacy preserving
identifiers are to be generated etc. I would suggest that line 2947 be
deleted, for example, as it deals with the mechanics of propagating and
updating identifiers.

[Scott]
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]


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.

- prateek