[Openid-specs-ab] ACR processing - MUST/Essential/Voluntary, order of preference

[John Bradley]

Messages 2.6.1 states that the array is in order of preference when you ask for it as a claim.   That didn't seem to get copied over when the acr_values was added but that should probably be corrected.

The server should only return an error if it is an essential claim and it cannot be fulfilled.

At the moment as claims are optional unless specified essential I would say that no error is required from the parameter version.  On the other hand we may want to specifically change that.
I agree that this ned to be clarified in the parameter description.


On 2013-06-24, at 11:28 AM, Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> wrote:

> Hi guys,
> 
> We were having an internal discussion on how to handle the ACR parameter
> in authz requests and I would like to ask for your advice:
> 
> 
> OIDC Messages draft 20 says the top level "acr_values" parameter values
> are to be treated as MUST. 
> 
> Does that mean the server must return an error if the ACR values are not
> supported? (as opposed to the composite "claims" parameter with ID token
> member "acr" where the only choice we have is between "essential" and
> "voluntary") If yes, which error code?
> 
> 
> Also, does the value order in "acr_values" matter? This seems to be
> implied by the definition of "values" in 2.6.1 Individual Claim
> Requests. The "default_acr_values" description in Registration also
> seems ambiguous on the value order.
> 
> 
> Thanks,
> 
> Vladimir
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130624/36f69f97/attachment.p7s>