RE: [security-services] Groups - draft-sstc-nameid-05.pdf uploaded

[Scott Cantor <cantor.2@osu.edu>]

> Item 1:
> The document uses the terms "identity provider" and 
> "authentication authority".  Only "identity provider" is 
> defined in the Definitions section, and the definition refers 
> to providing "Principal authentication".  I am not clear 
> whether or not these are used interchangeably or are intended 
> to specifically reference different services.

Authentication authority is a SAML defined term already. Identity provider
is not quite the same thing, but it includes or makes use of an authority to
issue authentication assertions.

Personally, though I borrowed these definitions from Liberty, I'd be
inclined to consider defining IdP and SP in the context of the browser
profiles, as I think that's a more explicit way of defining them.

> Item 2:
> The document specifically states that federations "must" be 
> explicitly consented to by the user.

John wrote the original requirements based on Liberty. Not even they
*really* treat this as a MUST. Politically, any standard that tries to
address this area runs afoul of some very serious privacy legislation.
Realistically, not every deployment has the same requirements.

That's why it ultimately belongs in the implementation guidelines document,
which is why I think SAML needs one.

> Affiliations would seem to be a means to address this 
> internal enterprise need.

Hmm, it's a way, but not really the main intention.

> The disadvantage I see is it would 
> force enterprise internal service providers to all adopt the 
> same identity for the user.  Given the myriad of legacy 
> systems in a large enterprise, synchronization of identities 
> among systems is not always possible.

Right, and affiliations would probably not be appropriate for that. You
could either do bulk federation by establishing shared names using whatever
keys exist between the systems, or consider using attribute-based approaches
that don't rely on actual account linking. Or many other approaches, I would
imagine.

My goal is to support, without requiring, Liberty-style account linking,
Shibboleth-style handles, traditional SAML identifiers, and anything else
somebody can come up with (Tony can chime in here) to solve their problem.

-- Scott