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

[Paul Madsen <p.madsen@entrust.com>]

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

Paul

>-----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)
>
>
>
>
>[Conor]
>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.
>[/Conor]
>
>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
>reads:
>
>[current-def]
>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
>principal.
>[/current-def]
>
>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 - 
>
>[proposed-definition]
>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.
>[/proposed-definition]
>
>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 
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php.