Re: [OAUTH-WG] New Token Introspection Draft

I thought someone mentioned it already: in the example you might want to send the request to /introspect instead of /register. It would be good to see user_id returned in the example too to get a better sense of what it really means (as I understand it, it's the username the user uses to sign in al

[OAUTH-WG] New Token Introspection Draft

I’ve updated the token introspection draft with the intention that this document become input for a new working group item. http://tools.ietf.org/html/draft-richer-oauth-introspection-05 The changes are mostly minimal edits to the text and a few reference fixes. One bigger change is the additio

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

This is the first time this draft has come up on the list so people coming up to speed is to be expected. In WS-Trust the security tokens are not tied to a single representation. /wst:RequestSecurityToken/wst14:ActAs This OTPIONAL element indicates that the requested token is expected to contai

[OAUTH-WG] FW: New Version Notification for draft-hunt-oauth-v2-user-a4c-04.txt

This version of the spec contains these changes: · Added a number of amr values. · Renamed the code_id_token response type to code_for_id_token. · Defined the code_for_id_token grant_type. · Removed the min_alv request parameter, since it's actually just a speci

Re: [OAUTH-WG] refresh tokens and client instances

Yes, The the undifferentiated is initially differentiated by the user during Authorization by having a code returned and then by exchanging the code for a refresh token. It however returns to being undifferentiated on subsequent authorization requests. This makes having sticky grants (only

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

ActAs the returned token is expected to be represented by the identity described by this parameter OnBehalfOf the request is being made by the identity described by this parameter These terms have been pretty clearly defined in the WS specifications, I don't understand the confusion. If section

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I pointed out a problem with the non normative text in sec 1.3 to Mike off list quite a while go. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, with on-beh

[OAUTH-WG] OAuth Dynamic Client Registration specs clarifying usage of registration parameters

An updated OAuth Dynamic Client Registration spec has been published that clarifies the usage of the Initial Access Token and Software Statement constructs and addresses other review feedback received since the last version. See the History section for more details on the changes made. The OAu

[OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-management-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Management Protocol Authors : Justin Richer

[OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-18.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Dynamic Client Registration Protocol Authors : Justin Richer

[OAUTH-WG] Review of draft-ietf-oauth-jwt-bearer-09

Hello, I just read through draft-ietf-oauth-jwt-bearer-09 and it looks good. The only question/comment I have is that I don't see any mention of privacy considerations in the referenced security sections. COuld you add something? It is easily addressed by section 10.8 of RFC6749, but there is n

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I don't think they do line up, at least not they way I read text from http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html and http://msdn.microsoft.com/en-us/library and /ee748487.aspx and *http://tools.ietf.org/html/draft-jones-oauth

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

Thanks, Mike! In-line... On Thu, Jul 3, 2014 at 4:03 PM, Mike Jones wrote: > Replies inline… > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] > *Sent:* Thursday, July 03, 2014 11:56 AM > > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] FW: JOSE

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

Replies inline… From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Thursday, July 03, 2014 11:56 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five Hello! Thank you for all of the upda

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

On Thu, Jul 3, 2014 at 3:38 PM, Mike Jones wrote: > I can add something along these lines. Does that work for you? > > > > *Privacy Considerations* > > A JWT may contain privacy-sensitive information. When this is the case, > measures must be taken to prevent disclosure of this information to

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I suspect it lines up. But Brian’s point may still be relevant. There is *long* standing confusion of the terms (because many of have different english interpretation than WS-Trust). Might be time for new terms? Impersonate (or even personate) vs. delegate ? Those terms differentiate between im

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

I can add something along these lines. Does that work for you? Privacy Considerations A JWT may contain privacy-sensitive information. When this is the case, measures must be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I’m lost too, as when I wrote this, I explicitly modelled it after WS-Trust. If there’s a concrete discrepancy you can point out, that would be great. FYI, I do plan to refresh this draft too allow for a more flexible trust model shortly.

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

I’m lost, the terms defined in the oauth token-exchange draft are the same terms defined in ws-trust and have the same definitions From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Thursday, July 3, 2014 12:02 PM To: Anthony Nadalin Cc: Vladimir Dzhuvinov; oauth@ietf.org Subject: Re:

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

And I was suggesting that OAuth token exchange align with the WS-Trust definitions or maybe even define totally new terms. But not use the same terms to mean different things. On Thu, Jul 3, 2014 at 12:55 PM, Anthony Nadalin wrote: > The explanation of on-behalf-Of and ActAs are correct in the

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

The explanation of on-behalf-Of and ActAs are correct in the document as defined by WS-Trust, this may not be your desire or understanding but that is how WS-Trust implementations should work From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, July 3, 2014 11:

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

Hello! Thank you for all of the updates to the JOSE drafts in the current bundle in review. I appreciate all of the effort that went into the revisions! As I understand it, there are a few general issues we need to work through, then a few nits/requests are included on specific drafts. Knowing

Re: [OAUTH-WG] draft-jones-oauth-token-exchange-00

FWIW, I am very interested in the general concept of a lightweight or OAuth based token exchange mechanism. However, despite some distaste for the protocol, our existing WS-Trust functionality has proven to be "good enough" for most use-cases, which seems to prevent work on token exchange from gett

Re: [OAUTH-WG] FW: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of five

Mike, Thanks for the updated JWT draft. I just read through it again and the changes look good. I noticed that privacy considerations were not mentioned. Should there be any discussed for claims, claim sets, etc.? This is bound to come up in the IESG review if it is not addressed. Sorry I did

Re: [OAUTH-WG] Agenda requests, please

I think you'll be okay time-wise. Since the JOSE + JWT drafts have been requested to go as a bundle, I'll have to make sure I get it on a telechat a little further out because of the amount of reading so the drafts get a fair review. We still have to start the IETF last call on those drafts as we

Re: [OAUTH-WG] Agenda requests, please

I just started a new job and won't be there, probably not listening in on the chat either On Thursday, July 3, 2014 10:39 AM, Brian Campbell wrote: Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit. Hopefully nothing will come up f

Re: [OAUTH-WG] Agenda requests, please

By the way, I will also not likely be in Toronto for most of the week due to the same conflict (thanks a lot, Ping), but I might be able to make it in time for the Thursday meeting depending on how travel arrangements get sorted out. — Justin On Jul 3, 2014, at 1:30 PM, Brian Campbell wrote:

Re: [OAUTH-WG] Agenda requests, please

Unfortunately I won't be in Toronto for #90 due to a conflict that week with the Cloud Identity Summit . Hopefully nothing will come up from the IESG on the assertion bundle but I trust Mike can handle it, if something requiring agenda time does surface between

Re: [OAUTH-WG] refresh tokens and client instances

You might have a public client, the Flickr client for example (which uses OAuth 1 right now but it's a useful example) where the client ID is baked into the install.  In this case binding the token to the client ID means only that someone who steals the token and tries to use it with a different

Re: [OAUTH-WG] refresh tokens and client instances

Hi On 03/07/14 16:40, Bill Mills wrote: Implementations may/SHOULD bind refresh tokens to specific client instances. Yes, it's possible that the client ID with dynamic registration is unique to each client, but many of the token theft use cases include the possibility of stealing the client ID t

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please)

Part if the lack of consensus is lack of agreement on what mgmt is for. Until that is resolved its hard to see what the timeline would be. Mgmt might be the right call. Who knows. For example i see credential rotation and client software update, and deprovisioning as being events. I am not sur

Re: [OAUTH-WG] refresh tokens and client instances

Implementations may/SHOULD bind refresh tokens to specific client instances.   Yes, it's possible that the client ID with dynamic registration is unique to each client, but many of the token theft use cases include the possibility of stealing the client ID too if you know you need to. -bill On

Re: [OAUTH-WG] refresh tokens and client instances

Hi I'm finding the answers from John interesting but I'm failing to understand why refresh tokens are mentioned in scope of identifying the specific client instances. AFAIK refresh tokens would only go on the wire, assuming they are supported, when a client exchanges a grant for a new access

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol (was Re: Agenda requests, please)

Hi Brian, Hi Justin, thanks for the quick feedback. Here is the status from the last meeting: http://www.ietf.org/mail-archive/web/oauth/current/msg12514.html I tried to put a date to the milestone on the charter page. When would this work be finished? Ciao Hannes On 07/03/2014 04:58 AM, Bria