Shibboleth Developers

["Scott Cantor" <>]

> Yes, I understand, but somehow LOA needs to be communicated back to
> the SP.

At the moment, attributes are probably the best way to do that, or some
community would need to profile AuthenticationMethod to be, essentially, a
2.0 context class or declaration, because it's normal 1.1 meaning is not
LOA.

The Feds use an attribute, FWIW.

> Grid SPs wish to base access control decisions on
> "authentication strength." 

But that is not LOA. That is one small part of LOA. If that isn't
understood, mistakes will ensue. Strong PKI + anybody gets a cert with no
proof = low LOA. SAML 1.1's strings don't communicate anything I would call
LOA.

> 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

This is not fodder for Shibboleth, it's fodder for InCommon or whatever your
deployment vehicle of choice is. What people SHOULD do is not something we
can decide here. We CAN help them implement their choice.

> 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?

See above, attributes or a shoehorning of stuff into AuthenticationMethod.
Or sure, if it's static, somebody could decide on a metadata extension. I
had a conversation with Ian about potentially extracting saml:Attribute
elements from entity metadata and publishing those alongside user
attributes, just to keep things relatively automatic.

> The other way to look at this is in terms of federation policy.

That's the *only* way to look at this, IMHO.

> I see that InCommon (e.g.) has a notion of "level of assurance" but is
> participation in InCommon based on LOA?

Not really, just sign the agreement and you document your practices, which
is essentially self-asserting the raw data that tends to impact 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?

It's not right now. It's handled OOB on the presumption that accepting
somebody's assertions is the result of due diligence. Understanding that for
many real world apps, zero effort is usually considered due diligence
because of where they started from.

-- Scott