Sorry, I should have read the full thread
The issue was raised.
Paul
>-----Original Message-----
>From: Paul Madsen [mailto:]
>Sent: Monday, March 15, 2004 8:38 AM
>To: 'Mishra, Prateek'; Conor P. Cahill; Scott Cantor
>Cc:
>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
>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.
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.
