[OAUTH-WG] Artart last call partial review of draft-ietf-oauth-iss-auth-resp-02

Review is partially done. Another assignment may be needed to complete it. Reviewer: Julian Reschke Review result: Almost Ready (I have reviewed this with zero knowledge of OAuth, so additional review probably would be good) Major issues: 2.4 "Clients MUST compare the extracted an

Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

Am 15.05.2021 um 17:57 schrieb Evert Pot: ... A more appropriate HTML tag might be the tag. You would just need to register a link relationship in the IANA registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml ... And that way, it could be sent in a Link response hea

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-18 13:37, Alexey Melnikov wrote: On 17/07/2012 19:01, Mike Jones wrote: You should actually probably make that name change request to the HTTPbis working group. I suspect that if they decide to change the name, that we could direct the RFC editor to make the same name change as HTTPb

Re: [OAUTH-WG] oauth-bearer and rfc 2617/httpbis authentication framework

On 2012-07-23 00:33, Stephen Farrell wrote: Hi all, I'd like to check that some recent minor changes to this document [1] don't cause technical or process-grief. The version [2] of the oauth bearer draft that underwent IETF LC and IESG evaluation had a normative dependency on the httpbis wg's

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 20:03, Julian Reschke wrote: On 2012-07-17 19:54, Mike Jones wrote: The change and the reason for it were called out to the working group in http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html. Indeed, as fait accompli. There were four days between the telco and the

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 20:01, Mike Jones wrote: You should actually probably make that name change request to the HTTPbis working group. I suspect that if they decide to change the name, that we could direct the RFC editor to make the same name change as HTTPbis does. ... HTTPbis describes the produc

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 19:54, Mike Jones wrote: The change and the reason for it were called out to the working group in http://www.ietf.org/mail-archive/web/oauth/current/msg09594.html. Indeed, as fait accompli. There were four days between the telco and the publication of the new draft for actually

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 19:39, Mike Jones wrote: Yes, the decision to remove normative references to HTTPbis was made during the public OAuth status call on Monday, July 9th, as the call participants wanted to be able to publish the RFC before HTTPbis is published as an RFC. Well, it would have been ni

Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 19:15, Mike Jones wrote: For clarity of discussion, the definition in question is: b64token= 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" Note that b64token is a liberal syntax intended to permit base64 encoded content (hence the in

Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt

On 2012-07-17 18:10, Mike Jones wrote: FYI, the b64 token definition is identical to the one in draft-ietf-httpbis-p7-auth-20. If it works there, it should work for OAuth Bearer. ... +1; not every constraint needs to be expressed in the ABNF. "b64token" is here so recipients can parse the hea

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 17:01, Julian Reschke wrote: On 2012-07-09 16:48, Mike Jones wrote: HTML5 is not cited because it's a working draft - not an approved standard. In what way is "the definition of the media type in HTML4 is known to be insufficient"? People have been successfully im

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 17:36, Mike Jones wrote: What's the syntax for defining UNICODENOCTRLCHAR in a better way? I'd be eager to incorporate that. I failed to find that part from your link. ... Just change UNICODENOCTRLCHAR = to UNICODENOCTRLCHAR = %x20-7E / %x80-D7FF / %xE000-FFFD / %x1

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 16:48, Mike Jones wrote: HTML5 is not cited because it's a working draft - not an approved standard. In what way is "the definition of the media type in HTML4 is known to be insufficient"? People have been successfully implementing form-urlencoding with it for quite some time.

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 15:55, Julian Reschke wrote: On 2012-07-09 09:08, Mike Jones wrote: A preliminary version of OAuth core draft -29 is attached for the working group’s consideration and discussion on today’s call. I believe that this addresses all issues that have been raised, including Julian’s

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

On 2012-07-09 09:08, Mike Jones wrote: A preliminary version of OAuth core draft -29 is attached for the working group’s consideration and discussion on today’s call. I believe that this addresses all issues that have been raised, including Julian’s issues about the ABNF, character sets, and for

Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published

On 2012-06-20 06:57, Mike Jones wrote: OAuth Core draft -28 has been published. Changes were: ·Updated the ABNF in the manner discussed by the working group, allowing username and password to be Unicode and restricting client_id and client_secret to ASCII. ... VSCHAR = %20-7E needs to

Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published

On 2012-06-20 16:51, Mike Jones wrote: Julian, I don't believe that it's the intent of either Eran or myself to ignore your concerns - far from it. That being said, what's frustrating from my personal perspective is that we've asked you to provide specific proposed text changes that would add

Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published

On 2012-06-20 13:07, Eran Hammer wrote: Julian - This is not the final draft. Mike pushed an update with the information available while I'm away. Another draft will follow next week. I will review the list and propose text (or ask questions) early next week. EH ... OK, thanks for the update

Re: [OAUTH-WG] OAuth Core -28 and Bearer -21 specs published

On 2012-06-20 06:57, Mike Jones wrote: OAuth Core draft -28 has been published. Changes were: ·Updated the ABNF in the manner discussed by the working group, allowing username and password to be Unicode and restricting client_id and client_secret to ASCII. ·Specifies the use of the application

Re: [OAUTH-WG] nits about definition of using form parameters

On 2012-06-19 00:17, Eran Hammer wrote: I believe the UTF-8 piece came from Brian Eaton a while back because of some security issue identified at Google. ... If there are security reasons to send an undefined media type parameter then they really should be spelled out. Best regards, Julian

Re: [OAUTH-WG] Proposed OAuth Core -28

On 2012-06-19 02:03, Mike Jones wrote: In cooperation with the chairs and Eran, I’ve produced the attached proposed OAuth Core -28 version. It updates the ABNF in the manner discussed by the working group, allowing username and password to be Unicode and restricting client_id and client_secret t

Re: [OAUTH-WG] nits about definition of using form parameters

On 2012-06-18 23:48, Mike Jones wrote: Hi Julian, Both the Core and Bearer specs already reference W3C.REC-html401-19991224 for the definition of application/x-www-form-urlencoded. That definition is useless because it doesn't specify character encoding. I'll leave it up to others to commen

[OAUTH-WG] nits about definition of using form parameters

Hi there, re : This needs a normative reference to a spec that defines the application/x-www-form-urlencoded media type (such as ). Looking at the media ty

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

On 2012-06-12 00:16, Mike Jones wrote: Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, should be ASCII, whereas username and password should be Unicode, since they are for humans. Per John's

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

On 2012-06-10 20:50, Mike Jones wrote: Thanks for your reply, Julian. Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and they're required to be used with Basic, I believe that that confirms that username and password must either be ASCII or ISO-8859-1, and given that

Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

On 2012-06-08 20:09, Mike Jones wrote: Hi Julian, The current draft restricts username and password to ASCII was because RFC 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617: "Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only w

Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF

On 2012-06-08 09:56, Mike Jones wrote: The attached proposed edits to the Core spec update the ABNF to remove the character set restrictions that working group participants had objected to, and to define common syntax elements, where appropriate. After working group review, I believe that these c

Re: [OAUTH-WG] ABNF elements for suggested WG review

On 2012-06-05 00:46, Mike Jones wrote: Is there an existing ABNF element already defined that both of you would suggest that we use instead of TEXT? For instance, is there one that allows all printable and horizontal whitespace ASCII characters? And one that allows all printable and horizont

Re: [OAUTH-WG] ABNF elements for suggested WG review

On 2012-06-05 00:40, Mike Jones wrote: OAuth Core doesn't use HTTPbis. Many of these parameters are often used as URI query parameters, so whatever encodings are specified must work there. What syntax and encodings would you suggest for the OAuth Core parameters that need to work with HTTP B

Re: [OAUTH-WG] ABNF elements for suggested WG review

On 2012-06-05 00:10, Mike Jones wrote: The main point of my message was to point out that the working group has not discussed the syntax for some the elements identified. I’m glad that it now is. Actually, the draft already contains or implies syntax restrictions for more fields than you listed,

Re: [OAUTH-WG] ABNF elements for suggested WG review

On 2012-06-05 00:03, Mike Jones wrote: RFC 2616 contains this restriction for the contents of TEXT fields: Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT is gone in httpbis. Ther

Re: [OAUTH-WG] ABNF elements for suggested WG review

On 2012-06-02 10:10, Mike Jones wrote: Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the syntax of a number of the OAuth protocol elements had not been previously defined. (Thanks, Sean, for having us do this!) I took a stab at specifying appropriate AB

Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method

On 2012-05-24 09:02, Mike Jones wrote: My recollection is that putting it in an appendix was explicitly rejected in the threads discussing the DISCUSS issues and no one on those threads pushed back afterwards, particularly after Dick's explanations of why it should stay. (Why these DISCUSS di

Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method

On 2012-05-18 09:15, Julian Reschke wrote: ... Did you consider to *also* move the whole section into an appendix, so that it's status is also reflected by the document structure? Best regards, Julian Hi, it would be awesome to see feedback on this (it has been mentioned during IE

Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method

On 2012-05-18 00:11, Mike Jones wrote: Dear working group members: I'm going through the remaining open issues that have been raised about the Bearer spec so as to be ready to publish an updated draft once the outstanding consensus call issues are resolved. This DISCUSS had been raised about th

Re: [OAUTH-WG] OAuth ABNF

On 2012-04-23 23:19, Eran Hammer wrote: During the IESG review of draft-ietf-oauth-v2, Sean Turner raised the following DISCUSS item (meaning, the specification is blocked until this is resolved): > 0) General: I found the lack of ABNF somewhat disconcerting in that > implementers would have

Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

On 2012-04-20 17:12, Michael Thomas wrote: ... To Paul's point about how easy it is for a server to support both, I'd retort that it's equally easy for a client to gin up JSON instead of XML. Pity the poor programmer who can't get their head around that gigantic change. On the other hand, having

[OAUTH-WG] where do error codes go?, was: Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

On 2012-04-10 16:03, Alexey Melnikov wrote: ... 2). Section "3.1. Error Codes" I've suggested to use an IANA registry for this field. Apparently there is already a registry created by . However this document doesn't register values

Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

Citing from Sean's dicuss (): 1) I'm hoping the answer to this one is "there's no problem" but I gotta ask and maybe the APPs ADs can confirm: Is there any issue with this specification using ABNF from [I-D.ietf-h

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-01.txt

On 2012-02-17 00:14, Eran Hammer wrote: I haven't seen much feedback so I assume this is almost ready for LC. I will apply the suggestions below and will request a WGLC for -02. EH You should align with the Bearer spec on referencing httpbis P7, and apply some of the changes we discussed for

Re: [OAUTH-WG] Last Call: (The

On 2012-01-25 03:14, Bjoern Hoehrmann wrote: ... +1 > ... If you want to keep the distinction, you should offer an argument why this is something individual schemes should regulate (since having the same rules for all schemes is much simpler). > ... Exactly. I've been asking this many times

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-25 01:03, Mike Jones wrote: Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when

Re: [OAUTH-WG] OAuth specs in IETF last call

On 2012-01-23 18:39, Peter Saint-Andre wrote: On 1/23/12 10:11 AM, Mike Jones wrote: FYI, the OAuth Core and Bearer specifications have reached IETF last call status - the last step before becoming RFCs. See the following notes from the Internet Engineering Steering Group (IESG). Well, "last

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 16:58, Julian Reschke wrote: On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard ... Ple

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 18:24, Mike Jones wrote: As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that thi

Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 16:46, The IESG wrote: The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' as a Proposed Standard ... Please see my comments in

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2012-01-04 23:17, Mike Jones wrote: There are actually two parts to “this” as I see it: 1. Defining the syntax for the acceptable contents of the scope, error, error_description, and error_uri parameters. 2. Defining the means by which these values are transmitted in WWW-Authenticate respons

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2012-01-04 22:40, John Bradley wrote: You are correct. the Core spec should include this. However for one reason or another it is not in the core spec and probably will not be, given that it is in last call. ... The datatracker says: "AD Evaluation::Revised ID Needed" (

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2012-01-01 20:41, Mike Jones wrote: I'll note that in some profiles, the Bearer challenge may be the only one that the application may legally use. In that case, there's no need to be able parse other challenges that the application can't fulfill in the first place. The application would

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2011-12-31 20:40, Mike Jones wrote: Maybe I misunderstood your position. If you agree that '\' may not occur in the INPUT string, then that issue can be closed. That was the working group consensus position, per the cited e-mails. I thought that you were arguing that syntax restrictions o

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2011-12-31 00:19, Mike Jones wrote: I did already back the statement that this is the working group consensus with the e-mails attached in this note sent to you on December 12, 2011: - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html I replied in

Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2011-12-29 22:18, Mike Jones wrote: You proposed, Julian "3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics." About some of Mark Nottingham's comments, Barry wrote "Let

[OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

On 2011-12-19 02:00, Mike Jones wrote: ... ON SPECIFYING ONLY A QUOTED-STRING SERIALIZATION: I understand and agree with your desire to promote code reuse. You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization f

Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

On 2011-12-19 02:01, Mike Jones wrote: Hi Julian, I'm glad to hear that you're not disagreeing with the decision to disallow '\' in certain parameter values. I think that knowing that brings us much closer to resolution on this issue. I think you misunderstood me. I was referring to the val

Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

On 2011-12-12 18:28, Mike Jones wrote: Julian, you should reread the (substantial) mailing list threads on this topic. As an example demonstrating the consensus, I've attached a pair of messages from a thread on this topic in which several people supported the input restriction to preclude ch

Re: [OAUTH-WG] FW: [apps-discuss] APPS Area review of draft-ietf-oauth-v2-bearer-14

Mike, On 2011-12-12 17:51, Mike Jones wrote: ... This parameter definition was a result of significant working group discussion and reflects a solid consensus position. Using the quoted > ... I have to object to this summary. If there was consensus, it was rough at best. Essentially, the tw

Re: [OAUTH-WG] AD review of draft-ietf-oauth-bearer-13

On 2011-11-03 00:21, Manger, James H wrote: 5) Section 3 ABNF allows "realm=foo;realm=bar;scope=baz;error=123" is that ok? Is processing clear for all cases? I don't think it is. The ABNF does not allow that. It requires commas as separators, not semi-colons. Indeed. It requires double quo

Re: [OAUTH-WG] AD review of draft-ietf-oauth-bearer-13

On 2011-11-02 17:45, Stephen Farrell wrote: ... 4) What is the realm attribute in section 3? What is a client expected to do with that? I guess it has to be different from how realm is used with e.g. Basic. (That might be my ignorance of HTTP details though;-) ... Is it different? If it is, it

[OAUTH-WG] draft-ietf-oauth-v2-bearer-13: ABNF for WWW-Authenticate

Hi there, the new draft has changed the ABNF for the challenge (), but I still believe this change is not sufficient (see for instance [1]). The base problem here is that the spec tries to define an ABNF for a header field

[OAUTH-WG] draft-ietf-oauth-v2-bearer-13: character encoding in form data

Hi there, I note that sending data using form-encoding () is still [0] underspecified. To encode data using the "application/x-www-form-urlencoded" media type, the producer needs to first map characters to octets, and onl

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits

On 2011-10-28 10:59, Julian Reschke wrote: On 2011-10-28 01:30, Manger, James H wrote: ... Perhaps a better approach is to: defined,,, and values as; add text saying senders MUST NOT use quoted-string's escape mechanism (so " and \ cannot appear in the values), though receivers

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-17 20:53, Eran Hammer-Lahav wrote: All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever. ... I noticed that this hasn't been done yet, but the bearer spec, f

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-12: ABNF nits

On 2011-10-28 01:30, Manger, James H wrote: ... Perhaps a better approach is to: defined,,, and values as; add text saying senders MUST NOT use quoted-string's escape mechanism (so " and \ cannot appear in the values), though receivers MAY use a standard quoted-string parser; say the value mu

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 17:33, Mike Jones wrote: By design, implementations can use existing quoted-string parsers, as these accept and correctly process all legal scope values. The spec is silent on what to do with illegal values, such as those containing \ or those not surrounded by ". Conforming imp

[OAUTH-WG] choice of credentials syntax, was: OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 01:38, Mike Jones wrote: ... ·Removed the #auth-param option from Authorization header syntax (leaving only the b64token syntax). ... I recommend that adding a rational, such as: "The b64token syntax was chosen over an extensible parameter syntax (see [HTTPbisP7], Section 2.3.1)

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 10:05, Julian Reschke wrote: On 2011-10-20 09:41, Mike Jones wrote: Your proposed wording for 2.4 misses the point: \ MUST NOT occur at all in the input string. No quoting may occur. > ... No, it doesn't miss the point. You need to tell implementers whether they c

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 09:41, Mike Jones wrote: Your proposed wording for 2.4 misses the point: \ MUST NOT occur at all in the input string. No quoting may occur. > ... No, it doesn't miss the point. You need to tell implementers whether they can use a quoted-string processor. Those processors will

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 09:14, Mike Jones wrote: Can you recommend specific wording changes to address both issues? 2.2: "The entity-body is encoded using the "application/x-www-form-urlencoded" media type (Section 17.13.4 of [W3C.REC-html401-19991224]), applied to the UTF-8 [RFC3629] encoded forms o

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 01:38, Mike Jones wrote: Draft 10 of the OAuth 2.0 Bearer Token Specification has been published, which incorporates consensus decisions reached since Wor

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-19 19:30, Marius Scurtescu wrote: On Wed, Oct 19, 2011 at 10:26 AM, Mike Jones wrote: Yes, it covers all the characters legal in URIs. Per earlier discussion on the list, scopes are not restricted to being URIs, as existing practice includes scope elements that are not URIs such a

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-18 17:38, Eran Hammer-Lahav wrote: Space is allowed inside a quoted string and is already not allowed inside each scope string. EHL ... a) yes. b) well: The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are def

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-17 20:53, Eran Hammer-Lahav wrote: All I agree with is to limit the scope character-set in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excluding " and \ so no escaping is needed, ever. You also need to have one character reserved as delimiter for multip

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-17 00:54, Eran Hammer-Lahav wrote: It's an open question for the list. EHL ... Well, as long as it is not restricted in the core spec, the bearer spec will have to handle the case (or document this as known technical omission, I guess). Best regards, Julian _

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-16 18:44, Mike Jones wrote: As Eran wrote on 9/30, "The fact that the v2 spec allows a wide range of characters in scope was unintentional. The design was limited to allow simple ASCII strings and URIs." ... I see. Thanks. Is this going to be clarified in -23? Best regards, Julia

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-16 07:12, Mike Jones wrote: In your note yesterday summarizing our proposed issue resolutions, you wrote "The scope field is yet another item that will not be shown to the user and it serves the purpose of an identifier for authorization comparison. So, we don't need to have any int

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-15 14:16, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Mike, this is not specific enough. A string could be defined as " A string is a sequence of zero or more Unicode characters [UNICODE]. " (as in RFC 4627), or as " 8-bit binary data without a NUL (hex 00) termination " (as in RADI

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-14 18:46, Mike Jones wrote: Indeed, recognizing that you're right that "you can't do that" with the current syntax, we decided to change scope to quoted-string so that it is compatible with HTTPbis and add the restriction that no "\" quoting may be present in the string (to simplify

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-14 17:52, Julian Reschke wrote: On 2011-10-14 17:42, Mike Jones wrote: Thanks for the useful discussion and the write-up, Hannes. For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-09: Open Issues & Proposed Resolutions

On 2011-10-14 17:42, Mike Jones wrote: Thanks for the useful discussion and the write-up, Hannes. For context, Hannes and I discussed how to resolve the remaining Bearer spec issues in a manner that meets the needs of implementations and will not generate objections during the IESG or IETF Last C

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-13 02:38, Manger, James H wrote: One possible syntax is: Bearer access_token=xyz_-123,more_info=pdq Ultimately though, the format of the bearer token is outside of the scope of the spec, and up to the participants to determine, including whether to use b64token syntax or params syn

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 20:26, Mike Jones wrote: Because b64token is existing practice > ... Anyway, how do you then send credentials that include the bearer token plus additional parameters? Example, please. Best regards, Julian ___ OAuth mailing list OAu

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 20:02, Mike Jones wrote: The syntax in HTTPbis is: credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ] The syntax in Bearer 09 is: credentials = "Bearer" 1*SP ( b64token / #auth-param ) As this conforms to HTTPbis, I don't see a problem. I think HTTPbis and Bea

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 16:32, Mike Jones wrote: Draft 09 allows either b64token or auth-params. Unless there's a working group consensus that this must change, both syntax options will be supported. -- Mike ... Mike, that doesn't work. The restriction in HTTPbis is th

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-10-12 02:06, Manger, James H wrote: > 2. The ABNF for does not comply with RFC 2617 "HTTP Authentication". So where are we on this? Any progress? Some progress. draft-ietf-oauth-v2-bearer-09 defines the “Authorization: Bearer ...” request header to match draft-ietf-httpbis-p7-auth

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-10 01:08, Manger, James H wrote: You can't "replace" quoted-string. A recipient will have to be able to parse multiple challenges in a single header field value. To do so, it has to understand the syntax of params using double quotes. It can't special-case the parsing based on what pa

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-07 16:15, Manger, James H wrote: Option 3 has a serious flaw in that it requires escaping the "\" in "\u", because it is the escape character in quoted-string. I think it's certain that people will be confused by that, and interop problems will happen (unless you have a strong test

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-07 11:17, Mike Jones wrote: Thus far, I believe those who have expressed opinions have been pretty evenly split between 2 and 3 on the scope issue. I’ve seen no support for 1 since I sent my request for opinions. Option 3 has a serious flaw in that it requires escaping the "\" in "\

Re: [OAUTH-WG] Proposed resolution for issue 26

On 2011-09-28 05:50, Manger, James H wrote: I'll have another go trying to explain the problem I see with the scope parameter in the Bearer spec. Consider a French social network that decides to offer an API using OAuth2. It chooses 3 scope values for parts of the API related to family, friend

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-05 01:56, William Mills wrote: Allowing URI requires allowing % encoding, which is workable. As far as the protocol goes URI is a form of space separated string and the protocol doesn't care. URI doesn't include quote or qhitespace in the allowed characters so there's no problem there.

Re: [OAUTH-WG] Proposed resolution for issue 26

On 2011-10-05 01:52, Mark Lentczner wrote: I think James has made the case that there is an issue clear. As for what to pick, I favor not restricting scopes in the core spec, and clearly specifying the way scopes will be presented in HTTP headers in the bearer spec. For the later, James supplie

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-04 20:38, Marius Scurtescu wrote: On Tue, Oct 4, 2011 at 11:07 AM, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: Existing practice is that simple ASCII strings like “email” “profile”, “openid”, etc. are used as scope elements. Requiring them to be URIs would brea

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-10-04 03:55, Mike Jones wrote: As editor, based upon James’ input, I’d like to expand the set of choices for the working group to consider by adding the possibility of using JSON string encodings for scope and error_description where the characters used for the encoding are restricted to

Re: [OAUTH-WG] Possible alternative resolution to issue 26

On 2011-09-30 14:03, Buhake Sindi wrote: Hi everyone, As for encoding, my understanding is that the scope parameter were scope fields provided by the service provider and that scope should match the service provider scope. Fair enough, we could argue that non-UTF-8 characters can't be sent over

Re: [OAUTH-WG] Proposed resolution for issue 26

On 2011-09-28 15:40, Barry Leiba wrote: I'd like to see more participation in this thread, besides just from Mike and James. What do others think? Barry, as chair ... I agree that if a protocol element needs to support non-ASCII characters, the spec should be *crystal clear* how it's going t

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

On 2011-09-26 22:10, Mike Jones wrote: Getting rid of the b64token would be an unnecessary breaking change. ... You're at draft state, right? If you want to keep b64token *and* be able to use params, then you'll need an alternate syntax that puts the token into param (which, arguably, would

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

On 2011-09-26 21:20, William Mills wrote: I'm gonna top reply... >> Is that intended and acceptable? No, b64token isn’t always there; the syntax specifies that either a b64token OR one or more auth-params will be present. Yes, that’s intended. If the token can be transported in auth-params

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

On 2011-09-26 21:03, Mike Jones wrote: ... No, b64token isn’t always there; the syntax specifies that either a b64token OR one or more auth-params will be present. Yes, that’s intended. OK then; just checking :-) > ... This was the working group decision at the interim meeting and is used in

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

On 2011-09-24 02:13, Mike Jones wrote: Thanks for your comments, Julian. Responses to them, which reflect the content of draft 09, follow inline. Thanks! ... 2.1. The Authorization Request Header Field The "Authorization" request header field is used by clients to make authenticated request

Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments

On 2011-08-31 08:39, Manger, James H wrote: William J. Mills said: Did item #2 below get resolved? I haven't seen any more traffic about it and it seems pretty significant. No, I haven’t seen any resolution for #2 (or any of these comments). The latest HTTPbis draft (http://tools.ietf.org/ht

[OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

Hi there, below a few comments on dependencies to HTTPbis, and the actual header field syntax. Best regards, Julian -- snip -- 1.1. Notational Conventions ... This document uses the Augmented Backus-Naur Form (ABNF) notation of [I-D.ietf-httpbis-p1-messaging], which is based upo

  1   2   >