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 closes 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. 

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