proposed addition to loa-authncontext doc re certified assurance

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

I am proposing to add a section to the loa-authncontext document to define 
an attribute to represent "certified assurance profiles" of an IdP, as 
stated by some certifying party, attached to an IdP entity's SAML 
metadata.  In our higher-ed identity federation 
(http://incommonfederation.org/) we are intending to move to this 
mechanism to distribute assurance certification information, and we've 
heard that other folks are looking for the same thing.  We'd like to see 
this specified in the loa-authncontext document rather than in a separate 
document.  Here's more description of all this.

The loa-authncontext doc defines a way for an IdP to indicate in a 
standard way that an assertion has been issued in compliance with an 
assurance profile.  This is good, but the question is:  why should an RP 
believe this info?  The answer could be:  this is set up out of band; but 
we think defining a standard way to do this would improve 
interoperability, and that using metadata for this is straightforward.

The proposed method would take advantage of the ability to add attributes 
to entities in metadata as specified in the metadata-attr draft.  An 
attribute name would be defined, perhaps:

   urn:oasis:names:tc:SAML:assurance-profile-certification

and that attribute can be added to IdP entities in metadata with values 
that indicate the assurance profiles that that entity can assert via 
loa-authncontext.  The party that is stating the certification is the 
issuer (signer) of the metadata containing that entity.

The processing rules for the consumer of the metadata (an RP) would be 
something like the following.  The assurance-profile-certification info is 
available to an RP to help it decide how to handle an authentication 
assertion that arrives with a particular stated assurance profile.  If the 
profile in the assertion is in the IdP's certified profile set, the RP can 
regard the assurance in the assertion as supported by metadata.  If it's 
not in the set, then it's up to the RP to decide what to do.  Some 
assurance profile frameworks may be ordered such that certification for 
one profile lets others be accepted (Level B certification makes Level A
OK also); it would be up to particular assurance frameworks to specify 
this.  Even if the assurance in the assertion is not in the certified set, 
the RP may still want to accept the assertion and proceed with an app 
session, perhaps taking other mitigation steps.

In discussions about this I think there has been some interest in having 
the ability for the attribute in the metadata be signed independently of 
the rest of the rest of the metadata.  If this is desired presumably there 
would need to be some spec text supporting it.

There has also been recent discussion of how to do this kind of thing in 
federations (or "federations") using protocols such as OpenID and WS-Trust 
(ie, Information Card) rather than SAML.  There may be a window of 
opportunity to achieve some commonality among the protocols for this 
stuff, which would be good.  Though perhaps if we really thought this 
would happen that might argue for this attribute being defined in its own 
doc, since the use of authncontext for sending LoA wouldn't apply to these 
other protocols.

It also occurs to me that the IGF technology might cover this area, but I 
don't know much about it.

Comments?  I know some people are anxious to get loa-authncontext finished 
...

  - RL "Bob"