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 closesAI #0114)


> In general, I have a problem with the entire use of the term "accounts"
> in any federation discussion.  Federation really is the process of
> two parties agreeing on a common handle for an entity.  What they do
> with that handle (e.g. associate it with an account on their system)
> is out of scope of the specifications and SAML.

I agree, but I don't read the suggested glossary terms as reading in that
direction. It's not that account linking is in the federation discussion,
but the opposite. If you share an identifier, you could link accounts. Or
not.

> Of course, as SSO initially rolls out, where users have local accounts
> on most systems, the shared handle will be associated with the local
> account and you can read that as a linked account.  I just don't want
> to burn this into the spec as the way that things should be done or
> that this is the only thing that can be done.

At the moment, even the concept of "federate" as a verb is not reflected
because there is no distinction between using an existing shared identifier
and the generation of a new shared identifier. In ID-FF 1.2 this is
reflected by distinguishing between "any/federated" and "none" in
NameIDPolicy, whereas core-07 offers no such distinction because I don't
think it's meaningful.

-- Scott



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