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

Nat Sakimura sakimura at gmail.com
Tue Jun 4 22:35:50 UTC 2013


Actually, the current text is saying SHOULD, so it is kind of OK, but Brian
was suggesting that we just reference the source doc and have no normative
text here, and I +1ed to it. That will avoid future conflicts when docs are
rev'ed independently.


2013/6/5 Mike Jones <Michael.Jones at microsoft.com>

>  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>****
>
> 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> 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>
> 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> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
>
> ** **
>
>  _______________________________________________
> Openid-specs-ab mailing list
> 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****
>



-- 
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/20130605/0ee1eae9/attachment-0001.html>


More information about the Openid-specs-ab mailing list