[Sigh, resending with corrected CC list]
OK, sounds like I didn't fully understand the context here. Providing
the examples you give as motivation would help keep others from making
the same mistake. . .
>> .1.2.5 In a somewhat parallel case, I would expect this section to
>> at least explain why the SHOULD NOT is not a MUST NOT. Since in
>> practice the distinction between trusted and untrusted 3rd-party
>> scripting is difficult if not impossible to draw, as written the 2nd
>> para is effectively overriden by the third.
> Assuming this means 184.108.40.206
> A MUST NOT is impossible to enforce here. You're telling people to
> party library that you include in your app could get access to the
> security bits whether it's on the callback page or not. I think it's
> appropriate to provide guidance for best practices here, and the
> MUST be first and SHOULD be only makes sense. People will get it
> wrong in spite of what the spec says here one way or another.
Hmmm. Either I'm misreading the text, or I don't understand your
argument. . . The existing "MUST NOT" para applies to untrusted js.
The second para. is nearly identical in terms of what it wants done,
but covers _all_ js. Writing MUST/SHOULD NOT and knowing people will
get it wrong just undermines the value of the spec.
> Suggestion: drop the requirements (and move them to the security
> doc), or otherwise no change.
If by that you mean, moving it to the security section, and observing
there that _failure_ to sanitise early is a risk, by effectively
changing MUST NOT to WILL RISK COMPROMISE and SHOULD NOT to MAY RISK
COMPROMISE, that would work for me.
No, I appreciate that you want to use registered short names in the
protocol, that's just fine. My problem is that you have left users,
developers etc. with no way to discover what shortnames have been
registered short of a non-trivial and error-prone informal search
What I'm asking for is support for probe URI prefixes for each family
of shortnames. So, just as today I use "text/n3" as the media type for
my Notation3 documents, I can check that this is a registered media
type by attempting to retrieve
and I can see all the registered text types by retrieving from
likewise I ought to be able to check e.g. the "bearer" token type by
attempting retrieval from (something along the lines of)
and I should be able to see all the registered token types by retrieving from
Hope this clarifies what I meant.
>> Minor Issues:
>> A short summary of the changes from OAuth 1.0/RFC5849 would have
>> been helpful, and it might still be a good idea to add one. . .
> I don't think this is possible. OAuth2 is built nfundamentally
> differently from OAuth1, so this paragraph might as well read "just
> about everything but the concept". Suggestion: don't add this,
> unless someone can come up with a succinct way to summarize the
> decision to build on a new foundation.
OK, thanks. Even something like the above short statement would be
useful . . .
>> 4.1 Would it be helpful to indicate that steps D&E may occur at
>> any time after C, and may be repeated subsequently?
> D&E may be delayed, but shouldn't be repeated. The Access Code is
> one-time-use, and in the best deployments will expire after a short
> period of time. Suggestion: leave as is.
OK, I just think as it is it invites misinterpretation.
>> 11.1 It might be useful to have an 11.1.2, which repeats references
>> to the bearer and mac access token type registration drafts?
> Is this a request to pre-register the two 'core' token types?
Yes, in that what I had in mind was making 11.1 parallel to ll.2, 3
and 4 in this regard.
[I'm sorry about the mailing list confusion. But please don't punish
me again by sending HTML change bar markup which I have to hand edit :-]
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
OAuth mailing list