Tatsuki-san, as a counter example, SSOCircle is a SAML IDP that support multiple authn methods (and so likely different LOA), and even hilites this http://www.ssocircle.com/auth_ctx/tour_1.html For such an IdP, the RequestedAuthnContext element on the AuthnRequest is one method by which the SP can direct the IdP. As you know, PAPE's authors did not give much credence to this use case ... paul Tatsuki Sakushima wrote:

It might be orthogonal to Paul's post, but I am wondering why ICAM OpenID profile declares LoA1 in the authentication policy.

In the "Programmed Trust" section, it defines how a RP finds trusted IDPs in the white list maintained by the ICAM. In the current profile, all IDPs listed in the WL are LoA1 providers.

The LoA1 in OMB M-04-04 is somewhat unique to other levels because it requires Pseudonyms(PPIDs) and no personal identified information. Those policies are defined separately from the LoA1 policy and used by IDPs to generate response messages.

If IDPs provide support more than one levels, stipulating a desired LoA makes sense but I haven't seen IDPs supporting multi-levels. RPs may be responsible to manage WLs for each levels to find IDPs to provide services they need. Why has the SSTC decided to declare LoA in request messages? Tatsuki

(12/14/09 7:32 AM), Paul Madsen wrote:

...

In the SAML & OpenID deployment guideline [1] for proxying between authncontext & PAPE, the fact that PAPE does not allow the RP to stipulate a specific desired LOA has been a limitation - specifically in the case where the proxy is trying to map from a SAML Authnrequest that had a specified LOA class into an OpenID request. Currently, the deployment guideline recommends the proxy fail the SAML request in this situation

However, the ICAM OpenID [2] profile forgoes the PAPE LOA mechanism and uses the more flexible authentication mechanism parameter to allow the RP to specify the ICAM LOA1 policy on the OpenID request.

If the ICAM profile were to set a precedent for how PAPE is used to carry LOA, then the above issue for proxying between SAML & OpenID is mitigated.

Thoughts?

Paul

[1] - http://bit.ly/4R6CJh [2] - http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf _______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

OMB M-04-04 doesn't require non correlatable identifiers. All LoA 1 identifiers are by definition pseudonymous because they are not identity proofed. ICAM requires non-coralatable identifiers for privacy reasons that are outside of OMB-04-04 and SP-800-63. A IMI info card can contain claims for LoA 1,2 and 3. A openID can only be LoA 1 because it dosn't meet the requirements of LoA 2. Once openID is suitable for LoA 2 and a IdP/OP is certified by a ICAM Trust framework provider, that IDP can step down a LoA 2 proofed account to make a LoA 1 assertion about it. IdP can step down but not up. John B. On 2009-12-14, at 7:08 PM, RL 'Bob' Morgan wrote:

...

The LoA1 in OMB M-04-04 is somewhat unique to other levels because it requires Pseudonyms(PPIDs) and no personal identified information. Those policies are defined separately from the LoA1 policy and used by IDPs to generate response messages.

I am not sure what you mean by this. OMB 04-04 says that what it calls "anonymous credentials" *may* be used with LoAs 1 and 2. The ICAM OpenID profile says that PPIDs must be used, but also permits other personal information to be requested by the RP and provided by the OP.

...

If IDPs provide support more than one levels, stipulating a desired LoA makes sense but I haven't seen IDPs supporting multi-levels. RPs may be responsible to manage WLs for each levels to find IDPs to provide services they need.

We're expecting that the typical US higher-education IdP will support multiple LoAs. It doesn't make sense to segregate populations into separate IdPs by LoA. We're also expecting that RPs requiring LoA will ask for the LoA they need, rather than having to configure IdPs to know which RPs require what.

- RL "Bob"

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

Sorry a IdP issuing a LoA 1 or 2 response as requested if the user is proofed and authenticated at LoA 2 is what I meant as step down. The user may have been proofed at LoA 2 at say PayPal. PayPal supports both IMI and openID. They could authenticate to PayPal with a LoA 2 infocard but if the assertion to the RP is over openID then it can only be LoA 1. So in the openID case it is step down because it is a LoA 1 assertion based on a LoA 2 primary authenticator. A LoA 1 secondary assertion can never be more then LoA 1 from the RP perspective even if the Primary authenticator is a LoA 4 PIV card. If the assertion is a LoA 3 SAML assertion and the user is proofed to LoA 3 and they have a choice of 2^18 entropy password, or LoA 4 PIV card. The assertion from a ICAM perspective is LoA 1 or LoA 3 depending on what they used as there primary authenticator. I say down, you say up perhaps its a northern vs southern hemisphere thing. There are three variables proofing, Primary Authenticator, and Secondary Authenticator/Assertion. The other thing to remember is that the user can't be allowed administrative access to the account if they are authenticated at the lower LoA without compromising the Higher LoA. That is something I would look for as an assessor for a multi LoA IdP. John B. On 2009-12-14, at 8:11 PM, Paul Madsen wrote:

John, I wouldnt characterize what you are describing (ie an OP being able to issue both LOA1 & LO2 assertions) as 'step-down'.

A 'step-up' scenario from LOA1 to LOA2 would be

proofing2+authn1 -------- (when requested by an RP) --------> proofing2+authn2

as you cant (easily) proof real-time, the only variable for the stepping up is the authentication mechanism.

But what you are describing is the OP just being able to issue either LOA1 or LOA2 as appropriate, given that the proofing supports both.

Paul

John Bradley wrote:

...

OMB M-04-04 doesn't require non correlatable identifiers.

All LoA 1 identifiers are by definition pseudonymous because they are not identity proofed.

ICAM requires non-coralatable identifiers for privacy reasons that are outside of OMB-04-04 and SP-800-63.

A IMI info card can contain claims for LoA 1,2 and 3.

A openID can only be LoA 1 because it dosn't meet the requirements of LoA 2.

Once openID is suitable for LoA 2 and a IdP/OP is certified by a ICAM Trust framework provider, that IDP can step down a LoA 2 proofed account to make a LoA 1 assertion about it.

IdP can step down but not up.

John B. On 2009-12-14, at 7:08 PM, RL 'Bob' Morgan wrote:

...

...

The LoA1 in OMB M-04-04 is somewhat unique to other levels because it requires Pseudonyms(PPIDs) and no personal identified information. Those policies are defined separately from the LoA1 policy and used by IDPs to generate response messages.

I am not sure what you mean by this. OMB 04-04 says that what it calls "anonymous credentials" *may* be used with LoAs 1 and 2. The ICAM OpenID profile says that PPIDs must be used, but also permits other personal information to be requested by the RP and provided by the OP.

...

If IDPs provide support more than one levels, stipulating a desired LoA makes sense but I haven't seen IDPs supporting multi-levels. RPs may be responsible to manage WLs for each levels to find IDPs to provide services they need.

We're expecting that the typical US higher-education IdP will support multiple LoAs. It doesn't make sense to segregate populations into separate IdPs by LoA. We're also expecting that RPs requiring LoA will ask for the LoA they need, rather than having to configure IdPs to know which RPs require what.

- RL "Bob"

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

+1 for large organizations have multiple LoA. I mentioned once upon a time a key driver is cost. In general higher LoA costs more money, so we only raise LoA where there is a business driver. It is also typically true that higher LoA is less convenient for the user. Mike Beach, CISSP Chief Security Designer Information Security The Boeing Company michael.c.beach@boeing.com -----Original Message----- From: dg-concordia-bounces@kantarainitiative.org [mailto:dg-concordia-bounces@kantarainitiative.org] On Behalf Of RL 'Bob' Morgan Sent: Monday, December 14, 2009 5:08 PM To: Concordials Subject: Re: [DG-Concordia] AuthnContext & PAPE & ICAM

The other thing to remember is that the user can't be allowed administrative access to the account if they are authenticated at the lower LoA without compromising the Higher LoA.   That is something I would look for as an assessor for a multi LoA IdP.

It is important to distinguish "multiple LoAs for the IdP as a whole, one LoA per user" from "multiple LoAs per user". The former, it seems to me, is going to be the case in any organization of any significant size. Multiple LoAs per user is definitely trickier and less obviously needed, though still relatively common (e.g. at my university many people have two-factor devices they use for more sensitive apps in addition the plain old username/password they use for all other apps). I don't know that I agree with your concern above in general, though. Our users have some kinds of "administrative access" to their accounts (update mailing address, eg, or change password) via LoA2 (-equivalent) login. This doesn't affect the quality of their two-factor (LoA3-equiv) login, as far as I can see. - RL "Bob"

On the topic of the relevance of RequestedAuthnContext, this SAML profile (http://saml2int.org/profile/current) recommends against RequestedAuthnContext - citing interop concerns. But surely the argument that authncontext complicates interop could be used against any policy parameter.... Paul On 12/14/2009 8:08 PM, RL 'Bob' Morgan wrote:

...

The other thing to remember is that the user can't be allowed administrative access to the account if they are authenticated at the lower LoA without compromising the Higher LoA. That is something I would look for as an assessor for a multi LoA IdP.

It is important to distinguish "multiple LoAs for the IdP as a whole, one LoA per user" from "multiple LoAs per user". The former, it seems to me, is going to be the case in any organization of any significant size. Multiple LoAs per user is definitely trickier and less obviously needed, though still relatively common (e.g. at my university many people have two-factor devices they use for more sensitive apps in addition the plain old username/password they use for all other apps).

I don't know that I agree with your concern above in general, though. Our users have some kinds of "administrative access" to their accounts (update mailing address, eg, or change password) via LoA2 (-equivalent) login. This doesn't affect the quality of their two-factor (LoA3-equiv) login, as far as I can see.

- RL "Bob"

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

is there a class of users who would always log-in at a higher LOA? Within the IdP enterprise, I'd guess not (i.e. even those users that require higher LOA credentials would also have a lower LOA mate) but perhaps not for federated actions at an SP? Paul On 12/14/2009 8:08 PM, RL 'Bob' Morgan wrote:

...

The other thing to remember is that the user can't be allowed administrative access to the account if they are authenticated at the lower LoA without compromising the Higher LoA. That is something I would look for as an assessor for a multi LoA IdP.

It is important to distinguish "multiple LoAs for the IdP as a whole, one LoA per user" from "multiple LoAs per user". The former, it seems to me, is going to be the case in any organization of any significant size. Multiple LoAs per user is definitely trickier and less obviously needed, though still relatively common (e.g. at my university many people have two-factor devices they use for more sensitive apps in addition the plain old username/password they use for all other apps).

I don't know that I agree with your concern above in general, though. Our users have some kinds of "administrative access" to their accounts (update mailing address, eg, or change password) via LoA2 (-equivalent) login. This doesn't affect the quality of their two-factor (LoA3-equiv) login, as far as I can see.

- RL "Bob"

_______________________________________________ DG-Concordia mailing list DG-Concordia@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-concordia

WRT: ----- At 12:44 PM -0500 on 12/15/09, Paul Madsen wrote:

is there a class of users who would always log-in at a higher LOA?

Within the IdP enterprise, I'd guess not (i.e. even those users that require higher LOA credentials would also have a lower LOA mate) but perhaps not for federated actions at an SP?

Paul

Interesting thread. I would offer a few observations. Most people want convenience. They will authenticate at the highest level they can and simply use that for everything. An example of an exception might be when travelling and using an Internet cafe where they can't use their PIV card so must revert to a password. A corollary of this is that RPs/SPs should be prepared to accept "higher" LOAs even if they only require "lower" ones. Consider also different "assurance profiles" where, e.g. Silver is a superset of Bronze so an RP/SP should be prepared to accept Silver even if Bronze is what it asks for. We've talked about different ways this could be handled and whether it is the IdPs responsibility to assert the overlap (e.g. this assertion is both Silver and Bronze) or whether the RP/SP should figure that out (e.g. Silver is as good as GSA LOA-2). The jury is still out on that one... Users that are astute may want to avoid operating at a higher privilege level than necessary so may choose to authenticate at LOA-2 for most of the time and then "step up" to LOA-3, e.g. with a second factor, when necessary. Can they subsequently revoke that step up? They should be able to without having to log out completely ... Other users may wish to have different personae for use with different aspects of their work or different communities. In this case, they may need to switch between "identities" within the same IdP which, of course, could have different LOAs. This could be a logout/login or maybe there could be a "I am now ..." FWIW. David