[DG-Concordia] AuthnContext & PAPE & ICAM

[Tatsuki Sakushima]

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 at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-concordia
>