[OAUTH-WG] JSON Web Token (JWT) and JSON Web Signature (JWS) now in separate specs

As promised, I have split the contents of the JWT spec draft-jones-json-web-token-01 into two simpler specs: draft-jones-json-web-token-02

Re: [OAUTH-WG] What's up with the secuity considerations? (was RE: Preview of -14)

Coming right after IETF-80 in -15. EHL From: Freeman, Tim [mailto:tim.free...@hp.com] Sent: Friday, March 25, 2011 5:16 PM To: Eran Hammer-Lahav; OAuth WG Subject: What's up with the secuity considerations? (was RE: Preview of -14) What's the plan for filling in the security considerations? In

[OAUTH-WG] pre-registered not relevant; figure 3 step E (was RE: Feedback on draft-ieft-oauth-v2-13.txt)

From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Since the redirection URI is required to be explicitly included > when using the authorization code grant type, the fact whether it > was pre-registered is irrelevant at this point. That makes sense, thanks. > The client simply has to pro

[OAUTH-WG] What's up with the secuity considerations? (was RE: Preview of -14)

What's the plan for filling in the security considerations? In the draft below I see: >9. Security Considerations > > [[ TBD ]] Tim Freeman Email: tim.free...@hp.com Desk in Palo Alto: (650) 857-2581 Home: (408) 774-1298 Cell: (408) 348-7536 From: oauth-boun...@ie

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Unless someone has an objection, I'll make the change from SHOULD to MUST. EHL > -Original Message- > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Friday, March 25, 2011 12:42 PM > To: Eran Hammer-Lahav > Cc: OAuth WG; Chuck & Mara Mortimore > Subject: Re: [OAUTH-WG] WGLC on draf

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

Regarding the message: http://www.ietf.org/mail-archive/web/oauth/current/msg05762.html (sorry I somehow lost the message in my email). This issue is theft of the authorization code during the redirect. Authenticating the client is an important feature and goes a long way, but it is not suffi

Re: [OAUTH-WG] Feedback on draft-ieft-oauth-v2-13.txt

> -Original Message- > From: Freeman, Tim [mailto:tim.free...@hp.com] > Sent: Friday, March 25, 2011 11:48 AM > Tim: > > Section 2.1.1 says "If a redirection URI was registered, the > > authorization server MUST compare any redirection URI received at the > > authorization endpoint with

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

That makes sense too. I'll change it to explicitly say case sensitive. Either way, this is a useful comment. EHL > -Original Message- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Friday, March 25, 2011 9:24 AM > To: Brian Campbell; Eran Hammer-Lahav > Cc: oauth@ietf.or

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

Authentication scheme names in HTTP are case insensitive. From: "Zeltsan, Zachary (Zachary)" To: 'Eran Hammer-Lahav' Cc: OAuth WG Sent: Friday, March 25, 2011 11:33 AM Subject: Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13   The spelling of the name “Be

Re: [OAUTH-WG] Feedback on draft-ieft-oauth-v2-13.txt

Snipping out everything I agree with, there's only this remaining, including some context so this email might make sense in isolation: Tim: > Section 2.1.1 says "If a redirection URI was registered, the authorization > server MUST compare any redirection URI received at the authorization > endpoi

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

The spelling of the name "Bearer" authentication scheme in the draft is inconsistent with the spelling in draft-ietf-oauth-v2-bearer-03. In draft-ietf-oauth-v2-13, section 7.1: "For example, the "bearer" token type defined...", and "Authorization: BEARER h480djs93hd8" In draft-ietf-oauth-v2-bea

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

Actually, despite having submitted this comment, I'm having second thoughts about it as well based upon some possible use cases I'm aware of. If, for instance, a scope element contains base64url encoded content in a URL, case-folding it will destroy it. Therefore, on reconsideration, I'd like

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

It didn't align with the my assumption when I was implementing, which is why I asked:) With respect to URIs, I believe that the scheme and host are always case-intensive but the case-sensitivity of the other parts are scheme dependent and that, in general, comparison is hard and error prone. It ju

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

It's a safe language to align it with common assumptions. Also, in the case of URI values, they are usually case insensitive. EHL > -Original Message- > From: Brian Campbell [mailto:bcampb...@pingidentity.com] > Sent: Friday, March 25, 2011 8:00 AM > To: Eran Hammer-Lahav > Cc: Mike Jone

Re: [OAUTH-WG] Feedback on draft-ietf-oauth-v2-13

>> 4.1.1:  Scope string matching rules are ambiguous >> >> In the "scope" definition, add "The space-delimited strings are case >> insensitive." > > Good call. I'd like to better understand why? Other than a means to delimit and allow for multiple values, the spec is otherwise leaving the interpr

[OAUTH-WG] Preview of -14

https://github.com/hueniverse/draft-ietf-oauth/raw/master/draft-ietf-oauth-v2.txt This includes all the feedback received until now. My queue is now empty except for the need to propose a new error code extensibility solution to accommodate the needs of protocol extensions. I replied back to al

Re: [OAUTH-WG] draft-ietf-oauth-v2-13 comments

Changed 'invalid_grand' to: The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. EHL > -Original Message- > From: Mark Kent [mailto:mk...

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Wednesday, March 23, 2011 2:27 PM > 1. I think it would help in the Introduction to state specifically that this > protocol is designed for use on the web and with

[OAUTH-WG] Authorization grant abstraction

OAuth2 now defines a single URI - the token endpoint - that has to be capable of processing: * State from a user approval interaction (encoded into a 'code' parameter); * User passwords; * Client app credentials; * SAML tokens; * JSON Web Tokens (JWT);

Re: [OAUTH-WG] (late) feedback on draft-ietf-oauth-v2-13.txt

How about: REQUIRED. The refresh token issued to the client. EHL > -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Paul Madsen > Sent: Tuesday, March 22, 2011 12:17 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] (late) feedback

Re: [OAUTH-WG] One more comment on draft-ietf-oauth-v2-13

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Lu, Hui-Lan (Huilan) > Sent: Thursday, March 17, 2011 2:31 PM > The required binding of the client and refresh token is implied. For clarity, > I > would suggest to make it explcit with t