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:]
>Sent: Friday, March 12, 2004 4:01 PM
>To: Conor P. Cahill; Scott Cantor
>Cc:
>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.
