Clarify the expected JSON type(s) of "value" and "values" in the claims request JSON object

[Vladimir Dzhuvinov]

Messages: 2.6.1. Individual Claims Requests

During implementation of our logic to parse the claims request JSON object I noticed that the type of the "value" and "values" member is not actually specified. The examples contain strings, but should we be prepared to expect other types as well?

Thanks,

Vladimir

[Michael Jones]

In the general case, the value could be of any JSON type, including string, number, Boolean, null, array, or object. In practice, so far I think all the claims that you might ask for particular values for are string-valued. (Of course, in theory, someone I suppose could ask for an "exp" value, which is numeric.)

I'm prone to think that we should add something to the spec like "the value requested must be a legal value for the requested claim, including being of the correct JSON type".

Would that language work for people?

[Michael Jones]

We will do that. John also suggested that we say that individual claim definitions may make requirements about the types of values that can be requested. The claims that this makes sense for at present are "sub" and "acr". For "acr", the valid values are those described in the discovery document.

[Michael Jones]

Fixed #835 - Clarified requirements on using "value" and "values" qualifiers when requesting specific values for individual claims.

→ <<cset 6c9dc59b1e9f>>

[Nat Sakimura]

A naive question.

What is the guidance between the requesting claims in 'claims' request parameter and the request object?

From what I see, 'claims' request parameter features are completely covered by request object. Main differences are that request object can specify other parameter such as response_types as well as other security parameters and can be signed (it is a compact serialized JWS), while 'claims' parameter is form encoded.

[Nat Sakimura]

Actually, I am asking the guidance between the use of 'claims' top-level parameter and 'request' parameter.

'claims' parameter was added by #748 to ease the writing of MTI and request parameter processing rules. From spec writing point of view, that is more elegant and fine. I just thought that developers who reads this spec may wonder when they should pick one or the other.

2013/6/3 Mike Jones [e-mail]

-- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en

[Nat Sakimura]

Probably an official readers guide type of thing would do.

For now, I just wanted to be ready to answer when I was asked.

=nat via iPhone

Jun 3, 2013 8:30、Mike Jones [e-mail] のメッセージ:

We already cover the rationale for using the “request_uri” in http://openid.net/specs/openid-connect-messages-1_0.html#RequestUriRationale. We could add similar rationale for when to use the “request” parameter, but I’d submit that adding this isn’t essential to completing the Implementer’s Drafts. We could write that and review it in a leisurely fashion, after publishing the Implementer’s Drafts, should the working group decide to do so.

                                                        -- Mike

[Michael Jones]

I know that we already say that you need to use “request” or “request_uri” when making a signed request. That’s the reason to use “request” over just bare parameters. I don’t think we need to say anything else in that regard, unless you have other reasons to use it.