Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01

I wrote code in the 4 biggest web languages for our signed_request. I'm sure it is a very small change to support JWTs. https://github.com/ptarjan/signed-request On 1/10/11 12:24 PM, "Dick Hardt" wrote: >Hi Jeff >FWIW: 1.5 yrs ago when I was at Microsoft working on OAuth WRAP, I >hacked up som

[OAUTH-WG] MAC: comments on draft-hammer-oauth-v2-mac-token-00

Comments on draft-hammer-oauth-v2-mac-token-00 1. The connection of this MAC scheme to OAuth is secondary. The primary function of the MAC scheme is to secure the authenticity of parts of an HTTP request using a shared secret. Secti

Re: [OAUTH-WG] OAuth MAC token type draft

> -Original Message- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, January 10, 2011 9:45 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > >> - Authentication schemes > >> You propose to use the auth

Re: [OAUTH-WG] OAuth MAC token type draft

>> - Authentication schemes >> You propose to use the authentication scheme name "OAuth2" for the >> WWW-Authenticate header but another scheme name "MAC" for the >> authorization header. I've never seen such an asymmetric approach before. >> Don't you think people get confused about that? > This

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

> -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Monday, January 10, 2011 3:25 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=code_and_token > > On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav >

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

On Mon, Jan 10, 2011 at 3:22 PM, Phil Hunt wrote: > What about the idea that the code is only used as a hand-off mechanism > between service components (e.g. authorization manager vs, resource access > manager).  In that case, the code would not be usable for anything except to > get an access

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

On 2011-01-10, at 3:25 PM, Brian Eaton wrote: > On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav > wrote: >> What about the difference between the two access tokens? The one issued >> directly and the one via the code? Are those the same? Same scope? Same >> duration? > > Same. > >> I thi

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav wrote: > What about the difference between the two access tokens? The one issued > directly and the one via the code? Are those the same? Same scope? Same > duration? Same. > I think this needs to be presented as a separate profile from the us

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

What about the idea that the code is only used as a hand-off mechanism between service components (e.g. authorization manager vs, resource access manager). In that case, the code would not be usable for anything except to get an access token (which still requires client auth). A code might hav

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

> -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Monday, January 10, 2011 2:53 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=code_and_token > > On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav >

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav wrote: > This explains why you want the code returned in the fragment, but not why you > need both code and token in the same response, as well as any differences in > the token attributes, The token in the same response is a latency optimizati

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

> -Original Message- > From: Brian Eaton [mailto:bea...@google.com] > Sent: Monday, January 10, 2011 2:31 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=code_and_token > > On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav >

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav wrote: > In -12, I am moving back to the -05 specification structure of profiles > (flows). Sweet! > This means this code_and_token hybrid needs to be explained beyond > just the definition of the extra parameter and response format. But I don’t

[OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

I'm having some doubts about the code_and_token response type. The reason why we have both token and code response type is that each has specific security characteristics. However, the mix raises questions about token scope and other properties. For example, -11 states that the scope in the tok

Re: [OAUTH-WG] OAuth MAC token type draft

> -Original Message- > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > Eran, > > - Authentication schemes > You propose to use the authenti

Re: [OAUTH-WG] OAuth MAC token type draft

I just wanted to bring these points up, but Torsten got there first! It only remains for me then to +1 on both. Igor Torsten Lodderstedt wrote: Eran, - Authentication schemes You propose to use the authentication scheme name "OAuth2" for the WWW-Authenticate header but another scheme name "M

Re: [OAUTH-WG] Error codes registry

I believe the draft should continue to say that the error code space MAY be extended. -- Mike From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, January 10, 2011 11:54 AM To: O

Re: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing"

Hannes, in my opinion, OAuth should stay a token-format independent protocol. So intuitively, I would vote to work on this topic within another group. Otherwise people might get the impression that OAuth is directly tied to a certain token format. regards, Torsten. Am 10.01.2011 10:19, schr

Re: [OAUTH-WG] OAuth MAC token type draft

Eran, - Authentication schemes You propose to use the authentication scheme name "OAuth2" for the WWW-Authenticate header but another scheme name "MAC" for the authorization header. I've never seen such an asymmetric approach before. Don't you think people get confused about that? Moreover, th

Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01

Hi Jeff FWIW: 1.5 yrs ago when I was at Microsoft working on OAuth WRAP, I hacked up some Perl code to generate and crack JWTs using HMAC as the signing mechanism. It was only about 10-15 lines of code. From my experience in building XML-DSIG libraries for Perl/Python/PHP/Ruby -- normalizati

Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01

Dick, thanks for the response. I think I'm behind everything you've said. Perhaps the crux is in library vs user/developer implementation. I'm interested in less steps not for computational overhead, but for mental overhead and usability. I would love to have (and even contribute) standard librari

[OAUTH-WG] Comments on OAuth 2.0 Bearer Token specification draft -01

Hi Mike, I've got some more comments on § 3.2 of your I-D. paragraph 4: "Encrypting the token contents is another alternative ..." How does token content encryption prevent the disclosure and abuse of a token? paragraph 5: "For those rare cases where the client is prevented from observing th

Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations

Independent of where this items belong to, the advice to only hand out tokens to authenticated clients is stronger as required by the core spec. There is a whole class of clients (native apps), which cannot keep secrets for the purpose of authentication. Moreover, what is the benefit of authen

[OAUTH-WG] Error codes registry

I am questioning the value of an explicit extension mechanism (and registry) for error codes. It seems like an overkill since name collisions are not likely or as problematic (given new error codes imply some other extension involved as well). I am going to drop notes about error code extensibi

Re: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10

> -Original Message- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Monday, January 10, 2011 8:48 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Feedback on normative issues in OAuth2 draft 11 from > implementers of draft 10 > > Our implementers of draft 10 h

Re: [OAUTH-WG] IETF#80: March 27-April 1, 2011

Blaine, Hanes, We plan to submit the next version of the draft on the OAuth use cases for the IETF 80. I would like to present it at the meeting. With thanks, Zachary -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: S

Re: [OAUTH-WG] Final cuts and 3 interoperable implementations

I'd like to be included on behalf of Huddle.com On Mon, Jan 10, 2011 at 4:47 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > please include me on behalf of Deutsche Telekom > > regards, > Torsten. > Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav: > > In the next few weeks I plan to

Re: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing"

Please put me in touch with the others who are working on JSON signing and encryption so we can coordinate our efforts. Thanks! -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behal

Re: [OAUTH-WG] JSON Web Token (JWT) draft -01

Not that I'm aware of at present, but I expect that to change shortly. -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Monday, January 10, 2011 1:04 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org Subject

Re: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10

> 5.1.3 etc.: The name client_credentials is confusing > The name client_credentials does not refer to the same concept as the uses of > the term “Client Credentials” in 1.4.3, 3, 5.1.3, and other locations in the > document. It would be far better to rename this parameter “none” or > “implic

[OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10

Our implementers of draft 10 have raised the following issues with draft 11. Please address them before publishing a draft 12. I'll send editorial feedback in a separate message. 6.2 etc.: Specification MUST permit parameter extensibility There will be uses of OAuth2 where additional parame

Re: [OAUTH-WG] Final cuts and 3 interoperable implementations

please include me on behalf of Deutsche Telekom regards, Torsten. Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav: In the next few weeks I plan to survey existing and planned implementations of each feature of the specification and those components without at least 3 interoperable (or complian

Re: [OAUTH-WG] OAuth MAC token type draft

Right -- if you substitute "token" with "client id" and "token secret" with "client secret", then you've got the makings for 2-legged OAuth 2.0 right there. I think you should call out that use case explicitly in your draft. -- Justin From: Eran Hammer-L

[OAUTH-WG] Re-Chartering: What Items to work on?

Hi all, In preparing the charter text we need your feedback. First, the new charter needs to include the two new items we had already accepted, namely * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ * The OAuth 2.0 Pr

[OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing"

Hi all, Mike had posted a mail about version -01 of the JSON Web Token document: http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html The usage of JSON and security applied to it became crucial to the work in OAuth. As we start our re-chartering it would be logical to add it to ou

Re: [OAUTH-WG] JSON Web Token (JWT) draft -01

I was wondering whether there is some running code available as well? On Jan 5, 2011, at 4:31 AM, Mike Jones wrote: > Draft -01 of the JSON Web Token (JWT) specification is now available. This > version incorporates the consensus decisions reached at the Internet Identity > Workshop. The rem