Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Torsten Lodderstedt
Deutsche Telekom also has an implementation.  regards, Torsten. Ursprüngliche Nachricht Von: Chuck Mortimore Datum:25.04.2014 01:31 (GMT+01:00) An: Mike Jones Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up Salesforce Implementa

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Chuck Mortimore
I do not have, nor am I aware of any, IPR on any of the technology in the document. thanks -cmort On Wed, Apr 23, 2014 at 1:40 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > I am working on the shepherd writeup for the JWT bearer document. The > shepherd write-ups for

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Chuck Mortimore
Salesforce Implementation: https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US On Thu, Apr 24, 2014 at 3:41 PM, Mike Jones wrote: > I am aware of these implementations: > Microsoft Azure Active Directory: > http://azure.microsoft.com/en-us/services

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Mike Jones
Thanks for doing the write-up, Hannes. I would suggest that the following changes be made in the write-up: Change "This document belongs to the OAuth assertion document bundle consisting of the abstract OAuth assertion framework, and the SAML assertion profile" to "This document belongs to t

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Mike Jones
I am aware of these implementations: Microsoft Azure Active Directory: http://azure.microsoft.com/en-us/services/active-directory/ Google Service Account: https://developers.google.com/accounts/docs/OAuth2ServiceAccount I believe that Ping Identity and Salesforce also have imple

Re: [OAUTH-WG] Minor questions regarding draft-ietf-oauth-json-web-token-19

2014-04-24 Thread Mike Jones
For what it's worth, the JOSE documents such as http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-25 also include the ECMAScript reference for the same reason as JWT does and Karen's shepherd write-up at http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/shepherdwrit

Re: [OAUTH-WG] HOTK/POP/etc drafts

2014-04-24 Thread Hannes Tschofenig
Btw, the HTTP signature mechanism now also got published as http://tools.ietf.org/html/draft-richer-oauth-signed-http-request-01 I think we now have a pretty good collection of documents to look at. Ciao Hannes On 04/24/2014 06:40 PM, Hannes Tschofenig wrote: > Hi Lewis, > > good that you ask.

Re: [OAUTH-WG] HOTK/POP/etc drafts

2014-04-24 Thread Hannes Tschofenig
Hi Lewis, good that you ask. In the London IETF meeting we have proposed a plan on how to proceed with the proof-of-possession (PoP) work. John had already explained that the main document is draft-hunt-oauth-pop-architecture-00. It pains the big picture and points to the relevant documents, in

[OAUTH-WG] Session cookies in OAuth2 flow

2014-04-24 Thread Andrei Shakirin
Hi, My name is Andrei Shakirin, I am working with OAuth2 implementation in Apache CXF project. Could you please help me to verify my understanding regarding of using session cookies in OAuth2 flow. OAuth2 specification mentions session cookies in: 1) Section 3.1. Authorization Endpoint as possib

Re: [OAUTH-WG] HOTK/POP/etc drafts

2014-04-24 Thread John Bradley
The overview document is draft-hunt-oauth-pop-architecture-00 For the client requesting POP tokens and key draft-bradley-oauth-pop-key-distribution For how to include the proof key info in a JWT (more generic than just access tokens) draft-jones-oauth-proof-of-possession The draft-sakimura-oau

[OAUTH-WG] HOTK/POP/etc drafts

2014-04-24 Thread Lewis Adam-CAL022
Hi, Lots of crypto drafts on OAuth popping up that I need to come up to speed on. draft-bradley-oauth-pop-key-distribution-00 draft-hunt-oauth-pop-architecture-00

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

2014-04-24 Thread Justin Richer
This is the intent of my draft (and results of my implementation), and if the WG ever picks up token introspection as a work item then we can make sure it says that. -- Justin On 04/24/2014 08:44 AM, Brian Campbell wrote: Perhaps it'd be more appropriate for this introspection endpoint to sa

Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00

2014-04-24 Thread Justin Richer
On 04/24/2014 05:06 AM, Hannes Tschofenig wrote: Hi Justin, thanks again for the quick response. A few notes below. On 04/23/2014 10:25 PM, Justin Richer wrote: Thank you for the review, responses inline (and this draft still needs to be factored back into the main one): On 04/23/2014 03:1

Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-16

2014-04-24 Thread Justin Richer
On 04/24/2014 04:55 AM, Hannes Tschofenig wrote: Hi Justin, thanks for the quick feedback. A few remarks below. - Protocol Flow In Figure 1 you show the client and the developer in the same box. The protocol defined in the specification clearly runs between a client and client registration e

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

2014-04-24 Thread Hannes Tschofenig
I will leave it to Justin to come up with the right wording. Ideally, we shouldn't have too many ways for the resource server to authenticate to the authorization server to avoid interoperability problems. On 04/24/2014 02:44 PM, Brian Campbell wrote: > Perhaps it'd be more appropriate for this

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

2014-04-24 Thread Hannes Tschofenig
Hi Brian, Thanks for pointing to the assertion framework document. Re-reading the text it appears that we have listed the case that in Section 6.3.1 but have forgotten to cover it elsewhere in the document. In Section 6.3.1 we say: " 6.3.1. Client Acting on Behalf of an Anonymous User Whe

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

2014-04-24 Thread Brian Campbell
Perhaps it'd be more appropriate for this introspection endpoint to say that it accepts the same client authentication mechanisms as the token endpoint rather than describing specific methods itself in the document? On Thu, Apr 24, 2014 at 3:09 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> w

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Hannes Tschofenig
Hi Brian, thanks for the quick response. On 04/24/2014 02:25 PM, Brian Campbell wrote: > I do not have, nor am I aware of any, IPR on any of the technology in > the document. > > Couple of little things on the writeup: > > "Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client > Authen

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

2014-04-24 Thread Brian Campbell
There is some discussion of that case in the assertion framework document at http://tools.ietf.org/html/draft-ietf-oauth-assertions-15#section-6.3.1 Do you feel that more is needed? If so, can you propose some text? On Thu, Apr 24, 2014 at 1:09 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net>

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

2014-04-24 Thread Brian Campbell
I do not have, nor am I aware of any, IPR on any of the technology in the document. Couple of little things on the writeup: "Writeup for "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" " -> should have "" Does the answer to 14 need more explanation? T

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

2014-04-24 Thread Hannes Tschofenig
Hi Brian, does it sound reasonable for you to add text to the token introspection endpoint regarding the use of the JWT bearer assertion for the token introspection endpoint? Ciao Hannes On 04/24/2014 12:58 AM, Brian Campbell wrote: > Just to pile on here - the Assertions draft(s) do define clie

Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-metadata-00

2014-04-24 Thread Hannes Tschofenig
Hi Justin, thanks again for the quick response. A few notes below. On 04/23/2014 10:25 PM, Justin Richer wrote: > Thank you for the review, responses inline (and this draft still needs > to be factored back into the main one): > > On 04/23/2014 03:14 PM, Hannes Tschofenig wrote: >> Hi all, >>

Re: [OAUTH-WG] Assertions: Client authentication for non-token endpoints?

2014-04-24 Thread Hannes Tschofenig
I believe that Mike is right that we might need to describe these aspects in the token introspection document. Ensure proper authentication of the resource server to the authorization server is extremely important for the security (particularly in context of the PoP work we are doing right now). I

Re: [OAUTH-WG] Minor questions regarding draft-ietf-oauth-json-web-token-19

2014-04-24 Thread Hannes Tschofenig
Thanks, Mike. Leave the ECMAScript reference in the document. I indicated it as a DOWNREF in the my shepherd write-up and that should be fine. Ciao Hannes On 04/23/2014 06:32 PM, Mike Jones wrote: > Replies inline... > > > > -Original Message- > From: OAuth [mailto:oauth-boun...@iet

Re: [OAUTH-WG] Review of draft-ietf-oauth-dyn-reg-16

2014-04-24 Thread Hannes Tschofenig
Hi Justin, thanks for the quick feedback. A few remarks below. >> - Protocol Flow >> >> In Figure 1 you show the client and the developer in the same box. The >> protocol defined in the specification clearly runs between a client and >> client registration endpoint at an authorization server. So

Re: [OAUTH-WG] draft-ietf-oauth-json-web-token-19 Shepherd Write-up

2014-04-24 Thread Hannes Tschofenig
Thanks, Brian. I will add this aspect to the write-up. On 04/24/2014 12:46 AM, Brian Campbell wrote: > While OAuth access tokens are a valuable application of JWT, might it > also be worthwhile to mention that JWT can and will be useful in other > contexts? Connect's ID Token is one such example:

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer-08 & subject issue

2014-04-24 Thread Hannes Tschofenig
Hi Brian, I read through the thread and the Google case is a bit different since they are using the client authentication part of the JWT bearer spec. There I don't see the privacy concerns either. I am, however, focused on the authorization grant where the subject is in most cases the resource o