Shibboleth Developers

[Tom Scavo <>]

On 2/15/06, Walter Hoehn 
<>
 wrote:
> On Feb 15, 2006, at 10:21 AM, Tom Scavo wrote:
>
> > 2. Either profile the use of the AuthenticationMethod attribute in the
> > Shibboleth profiles or map the SAML 1.1 values to LOA at the
> > federation level.
>
> I'm not sure I understand what we would profile in Shibboleth.  The
> authN method stuff is already in the SAML 1.1 spec.  With respect to
> level's of assurance, authentication method is only one of many
> inputs into any LOA algorithm.

Yes, I understand, but somehow LOA needs to be communicated back to
the SP.  Grid SPs wish to base access control decisions on
"authentication strength."  The only vehicle to communicate this (that
I know of) is AuthenticationMethod.  So AuthenticationMethod needs to
be some value that SPs know how to interpret.

So IdP deployments SHOULD populate AuthenticationMethod with values
SPs MAY use to make access control decisions.  These values MUST be
consistent across IdPs.  For example, what are the semantics of

urn:oasis:names:tc:SAML:1.0:am:password

I don't quite know what 'password' means in this case.  SAML 2.0 does
a better job of this (Password, InternetProtocolPassword,
PasswordProtectedTransport, SecureRemotePassword) so I guess my
question is how do we make these kind of fine-grain distinctions in
SAML 1.1?

The other way to look at this is in terms of federation policy.  I see
that InCommon (e.g.) has a notion of "level of assurance" but is
participation in InCommon based on LOA?  If so, how is this notion
captured in static metadata?  If not in metadata, how is LOA
transported over the wire in SAML assertions?

I don't have answers to these questions, but a number of people here
have made it clear that LOA is an issue for them with respect to
federated identity and federated attributes.  For them, the term
"Shibboleth" is the embodiment of these issues.

Tom