[Openid-specs-ab] Is it SHOULD or MUST?
sakimura at gmail.com
Tue Jun 4 21:41:59 UTC 2013
+1 to not to use a normative language here and just defer it to the
Multiple Response Type doc or a profile doc.
FYI, the Multiple Response Type doc. is using SHOULD.
If we want to allow something like postMessage, we should not be too
It is a core specification, and we have to have some room to move around.
SHOULD is OK, but perhaps just saying "as in Multiple Response Type"
As to the normative language use is concerned, I have done a fresh pass of
the Messages and found a lot of them too restrictive. We have been fixated
with the idea of the user agent being a web browser or smart phones. That
assumption is not true. It could very well be a fridge with blinking LED
light, so MUST in anything related to a user interface is a bit too much.
SHOULD is the strongest language we can use.
Similarly, we have been stepping on potential regulatory issues with MUSTs.
We have to avoid them as well.
I have not read Registration, Discovery, Basic, and Implicit in this
respect. I encourage you guys to read them in this respect. Even just
critically reading those MUST and MUST NOT would help.
2013/6/5 Brian Campbell <bcampbell at pingidentity.com>
> I've also got a draft of a POST style response type, FWIW.
> It shouldn't be a MUST. But SHOULD probably isn't right either. Response
> types are terribly confusing (we often use text like "includes the
> string" which is convenient but not technically correct) but that ship has
> What I'm suggesting is that OAuth 2.0 Multiple Response Type Encoding
> Practices deal with the response type situation. Any normative language in
> the other docs is likely only to cause inconsistencies or other problems.
> On Tue, Jun 4, 2013 at 9:04 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> It was left open to allow a POST message response to be defined in
>> Future. Google has a draft for that but it has not been advanced yet. So
>> no to MUST.
>> Sent from my iPhone
>> On 2013-06-04, at 4:28 PM, Brian Campbell <bcampbell at pingidentity.com>
>> One way or the other it should match up to OAuth 2.0 Multiple Response
>> Type Encoding Practices so as not to have inconsistencies in the spec
>> It's maybe better to not have a MUST or SHOULD here at all.
>> On Sat, Jun 1, 2013 at 7:09 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>> In the 2nd paragraph of
>>> 188.8.131.52. End-User Grants Authorization
>>> of Standard, it states:
>>> Note that if the response_type parameter in the Authorization Request
>>> includes the string value token or id_token, all response parameters
>>> SHOULD be added to the fragment component of the redirection URI.
>>> Otherwise, the response parameters are added to the query component of the
>>> redirection URI.
>>> Is it SHOULD? Is it not MUST?
>>> SHOULD means that it can be sent otherwise, e.g., as query string.
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab