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 c loses AI #0114)

Prateek's definition for a federated identity, with its emphasis on an
'identifier', would appear to exclude roles-based scenarios.

To my mind, if a Principal's role attribute at one provider is recognizable
and understood at another, this is still a federated identity, albeit
probably anonymous.

Or, was the intent that 'a class of identifiers' in the definition addressed


>-----Original Message-----
>From: Mishra, Prateek [mailto:pmishra@netegrity.com]
>Sent: Friday, March 12, 2004 4:01 PM
>To: Conor P. Cahill; Scott Cantor
>Cc: security-services@lists.oasis-open.org
>Subject: RE: [security-services] Comment on 
>sstc-saml-glossary-2.0 (also
>c loses AI #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.
>Agreed, I now see that the business about "accounts" is 
>unnecessary, we just
>need to focus on the part about "two parties agreeing on a 
>common handle". 
>Unfortunately, the current definition of identity federation 
>in the glossary
>Linking accounts for a given principal at a pair of providers within a
>federation by establishing (or using an existing) identifier 
>to refer to the
>Also note that the current definition conflates the 
>construction of identity
>federation with its existence. Given how important this topic 
>is, I would
>argue that we should start by separating these two notions.
>So lets try some alternate language - 
>An principal's identity is said to be federated between a pair (set) of
>providers when there is agreement between the providers on an 
>identifier (or
>a class of identifiers) and a time-period during which the 
>identifier is to
>be used to refer to the principal.
>Many different policies could be used to govern the chosen 
>identifier. For
>example, providers might agree to any one of the following identity
>federation policies:
>(1) a random number is generated for each principal every time they
>authenticate at an IdP
>(2) a random number is generated at some arbitrary time 
>intervals by the IdP
>or any SP and used to refer to the principal
>(2) a random number is generated for each principal and this number is
>persistently maintained for XX years 
>(3) Every principal belonging to some group at the IdP is 
>assigned the same
>identifier and this number is persisted for XX years
>Exactly how the federation identifier is created, updated, 
>shared between
>providers is yet another dimension to the discussion. SAML 2.0 
>provides some
>means of propagating federation identifiers, but I would 
>expect that there
>would be many other ways of managing identifier life-cycles as well. 
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 

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