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

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

Sorry, I should have read the full thread

The issue was raised.

Paul

>-----Original Message-----
>From: Paul Madsen [mailto:p.madsen@entrust.com]
>Sent: Monday, March 15, 2004 8:38 AM
>To: 'Mishra, Prateek'; 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)
>
>
>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.

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.