[Openid-specs-ab] Is it SHOULD or MUST?

Mike Jones Michael.Jones at microsoft.com
Tue Jun 4 21:56:00 UTC 2013


OK, I'll plan to revise the MUST to just be a reference to "as in Multiple Response Types".

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Tuesday, June 04, 2013 2:42 PM
To: Brian Campbell
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Is it SHOULD or MUST?

+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 prescriptive.
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" suffices.

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<mailto: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 sailed.
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<mailto: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<mailto:bcampbell at pingidentity.com>> wrote:
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 suite.
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<mailto:sakimura at gmail.com>> wrote:
In the 2nd paragraph of
2.2.6.1.  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
http://nat.sakimura.org/
@_nat_en

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130604/c09dd12f/attachment.html>


More information about the Openid-specs-ab mailing list