paul
RL 'Bob' Morgan wrote:
alpine.LFD.1.10.0905191037010.13485@localhost.localdomain" type="cite">
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"
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.42/2137 - Release Date: 05/27/09 07:50:00
--
Paul Madsen
e:paulmadsen @ ntt-at.com
m:613-282-8647
web:connectid.blogspot.com
Paul Madsen
e:paulmadsen @ ntt-at.com
m:613-282-8647
web:connectid.blogspot.com