Re: [OAUTH-WG] New Token Introspection Draft

[Thomas Broyer]

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 along with his password)
Le 4 juil. 2014 02:10, "Justin Richer"  a écrit :

> 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 addition of the “user_id” field in addition
> to the “sub” field, as I’ve been asked by some users to add that feature to
> our own implementation here.
>
>  — Justin
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] New Token Introspection Draft

[Justin Richer]

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 addition of the “user_id” field in addition to the “sub” 
field, as I’ve been asked by some users to add that feature to our own 
implementation here.

 — Justin


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 contain 
information about the identity represented by the content of this element and 
the token requestor intends to use the returned token to act as this identity. 
The identity that the requestor wants to act-as is specified by placing a 
security token or  element within the 
 element.


Is clear that the resulting token contains information about the identity 
represented by the security token passed as the content of the ActAs element 
and that the requester wants to act-as is that identity.

Depending on the resulting security token that may be represented differently.  
 Nothing explicitly states that the identity of the requester is in the 
resulting token, however when SAML tokens are used it typically is represented 
along with the identity to act-as.   

OnBehalfOf being older was treated as a proxy type request On-Behalf-Of the 
initial subject resulting in a token for the Original subject that may have 
been used by another party such as the requester.

So Sec 1.3 may be trying to describe composite tokens vs single subject tokens 
that may be beyond the scope of those token independent parameters in WS-Trust.

It is probably fair to say that from the way those parameters are implemented 
for SAML tokens in many if not all STS the description seems backwards.

Having something that describes how the output token varies based on input for 
typical token types might help make it more concrete for people.

John B.

On Jul 3, 2014, at 5:55 PM, Anthony Nadalin  wrote:

> 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 1.3 is confusing, I’m OK with 
> dropping this
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Thursday, July 3, 2014 2:44 PM
> To: Phil Hunt
> Cc: oauth@ietf.org
> Subject: 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-behalf-of semantics, principal A still has its own identity
>separate from B and it is explicitly understood that while B may have
>delegated its rights to A, any actions taken are being taken by A and   
>not B. In a sense, A is an agent for B.
>On-behalf-of semantics are therefore different than impersonation
>semantics, with which it is sometimes confused.  When principal A
>impersonates principal B, then in so far as any entity receiving
>Claims is concerned, they are actually dealing with B. It is true
>that some members of the identity system might have awareness that
>impersonation is going on but it is not a requirement.  For all
>intents and purposes, when A is acting for B, A is B.
>  
> OnBehalfOf  "indicates that the requestor is making the request on behalf of 
> another." and returns a security token to the requestor that contains a 
> single set of claims.
>  
> ActAs provides a security token/ assertion about subject A in a request from 
> Requester B and the response is a composite token that has Requester B as the 
> subject but also includes claims about subject A.
>  
> See MS FAQ to clarify this  popular question 
> http://msdn.microsoft.com/en-us/library/ee748487.aspx
>  
> I think this is what Brian was trying to get at. 
>  
> If we can't all agree on the semantics of OnBehalfOf (It has been around for 
> a long time) then we have a problem and should pick different terms.
>  
> The normative text is correct, however sec 2.2 adds an optional "actor" claim 
> to the initial JWT that is to be presented as the value of  on_behalf_of in 
> the request.  That is an addition to the WS-Trust text and took me several 
> reads to understand that it is not a element in the JWT response. 
>  
> I offered to help with the spec as I think it is useful.  The semantics are 
> tricky for people to understand so I was not all that concerned that the 
> first draft was not perfect.  
>  
> I suspect some concrete examples will help.
>  
> John B.
>  
> On Jul 3, 2014, at 3:51 PM, Phil Hunt  wrote:
> 
> 
> 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 ter

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

[Mike Jones]

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 
special case of acr_values. (For instance, "min_alv=3" meant the same thing as 
"acr_values=3 4".)

· Added an appendix describing the deltas from OpenID Connect.

-- Mike



-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, July 03, 2014 3:11 PM
To: Phil Hunt; Anthony Nadalin; Phil Hunt; Mike Jones; Anthony Nadalin; Mike 
Jones
Subject: New Version Notification for draft-hunt-oauth-v2-user-a4c-04.txt





A new version of I-D, draft-hunt-oauth-v2-user-a4c-04.txt

has been successfully submitted by Michael B. Jones and posted to the IETF 
repository.



Name:  draft-hunt-oauth-v2-user-a4c

Revision:  04

Title:  Providing User Authentication Information to OAuth 
2.0 Clients

Document date:   2014-07-03

Group:  Individual Submission

Pages:   15

URL:
http://www.ietf.org/internet-drafts/draft-hunt-oauth-v2-user-a4c-04.txt

Status: https://datatracker.ietf.org/doc/draft-hunt-oauth-v2-user-a4c/

Htmlized:   http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-04

Diff:   http://www.ietf.org/rfcdiff?url2=draft-hunt-oauth-v2-user-a4c-04



Abstract:

   This specification defines a way for OAuth 2.0 clients to verify the

   identity of the End-User and obtain consent based upon the

   authentication performed by an Authorization Server.  The

   interactions defined by this specification are intentionally

   compatible with the OpenID Connect protocol.









Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 asking for permission for incremental 
scopes) a potential security problem, as the AS has no way to know if the 
client is the one that the pervious authorization was intended for. 

Some AS just assume that you want the same permissions across all instances of 
a client,  however if this is a public client then someone could impersonate 
the client app and basically do privilege escalation.

What dynamic client registration gives us for native apps is a way to identify 
specific instances of clients at the authorization endpoint by having different 
client_id and validating that with instance specific client credentials.  This 
also prevents the use of code if it is intercepted in the reply from the 
authorization endpoint.

John B.

On Jul 3, 2014, at 12:28 PM, Sergey Beryozkin  wrote:

> 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 too if you know
>> you need to.
>> 
> What exactly is a 'client instance' when we talk about having a single client 
> id registration, with the id shared between multiple devices (which is what I 
> believe this thread started from).
> 
> What I understood, as far as the authorization service is concerned, a 
> 'client instance' for AS is a combination of a client id + code grant.
> 
> + (optional) refresh token (as was mentioned earlier). But it appears to me a 
> client instance can be uniquely identified by two values only without a 
> refresh token.
> 
> When a user authorizes a given device and gets a grant code and enters it 
> into the device securely we have a 'client instance' ready to get the tokens, 
> with that device (client instance) using a client id and the grant code to 
> get an access token and a refresh token.
> 
> Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
> A client id + a code value constitutes a client instance, because a code 
> would be unique per every authorization, right ?
> 
> So the service will return an access token + refresh token to the device. 
> Refresh Token could've been associated with a record containing a client id + 
> grant code info earlier or at the moment the code is exchanged for an access 
> token.
> 
> During the subsequent refresh token grant request we have "client id + 
> refresh token" as a client instance.
> 
> I'm not sure what exactly I'd like to ask here :-), but I wonder if the above 
> sounds right, then I guess I'd like to conclude that when we talk about the 
> authorization code grant then a refresh token is not the only key that 
> uniquely identifies a client instance:
> 
> Initially it is a client id + code grant, a refresh token does not offer an 
> extra uniqueness at the point of the client device requesting an access token 
> with a code. Refresh token only starts acting as the key client instance 
> identifier at a refresh token grant time.
> 
> Sorry for a long email, I'm very likely missing something, so any 
> clarifications will be welcome
> 
> Thanks, Sergey
> 
> 
> 
> 
> 
> 
> 
>> -bill
>> 
>> 
>> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>>  wrote:
>> 
>> 
>> 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 token.
>> And when the client uses a refresh token grant.
>> 
>> Was it really about a refresh token grant where the incoming client id
>> and refresh token pair can uniquely identify the actual client instance
>> ? That would make sense.
>> 
>> Something else I'd like to clarify.
>> John mentions a refresh token is created at the authorization grant
>> initialization time. Would it make any difference, as far as the
>> security properties of a grant are concerned, if refresh token was only
>> created at a grant to access token exchange point of time ?
>> 
>> Thanks, Sergey
>> 
>> On 27/06/14 19:21, John Bradley wrote:
>> > Inline
>> >
>> > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri > 
>> > >> wrote:
>> >
>> >> Hi John,
>> >> Thank you for your reply. Would appreciate if you consider my inline
>> >> comments below and respond again!
>> >> R,
>> >> Madjid
>> >> *From:*John Bradley [mailto:ve7...@ve7jtb.com
>> ]
>> >> *Sent:*We

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

[Anthony Nadalin]

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 1.3 is confusing, I'm OK with dropping this

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, July 3, 2014 2:44 PM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: 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-behalf-of semantics, principal A still has its own identity

   separate from B and it is explicitly understood that while B may have

   delegated its rights to A, any actions taken are being taken by A and

   not B. In a sense, A is an agent for B.

   On-behalf-of semantics are therefore different than impersonation

   semantics, with which it is sometimes confused.  When principal A

   impersonates principal B, then in so far as any entity receiving

   Claims is concerned, they are actually dealing with B. It is true

   that some members of the identity system might have awareness that

   impersonation is going on but it is not a requirement.  For all

   intents and purposes, when A is acting for B, A is B.

OnBehalfOf  "indicates that the requestor is making the request on behalf of 
another." and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at.

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional "actor" claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response.

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:


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 impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Jul 3, 2014, at 12:20 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


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.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: 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: [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 
mailto:tony...@microsoft.com>> wrote:
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

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

[John Bradley]

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-behalf-of semantics, principal A still has its own identity
   separate from B and it is explicitly understood that while B may have
   delegated its rights to A, any actions taken are being taken by A and   
   not B. In a sense, A is an agent for B.
   On-behalf-of semantics are therefore different than impersonation
   semantics, with which it is sometimes confused.  When principal A
   impersonates principal B, then in so far as any entity receiving
   Claims is concerned, they are actually dealing with B. It is true
   that some members of the identity system might have awareness that
   impersonation is going on but it is not a requirement.  For all
   intents and purposes, when A is acting for B, A is B.

OnBehalfOf  "indicates that the requestor is making the request on behalf of 
another." and returns a security token to the requestor that contains a single 
set of claims.

ActAs provides a security token/ assertion about subject A in a request from 
Requester B and the response is a composite token that has Requester B as the 
subject but also includes claims about subject A.

See MS FAQ to clarify this  popular question 
http://msdn.microsoft.com/en-us/library/ee748487.aspx

I think this is what Brian was trying to get at. 

If we can't all agree on the semantics of OnBehalfOf (It has been around for a 
long time) then we have a problem and should pick different terms.

The normative text is correct, however sec 2.2 adds an optional "actor" claim 
to the initial JWT that is to be presented as the value of  on_behalf_of in the 
request.  That is an addition to the WS-Trust text and took me several reads to 
understand that it is not a element in the JWT response. 

I offered to help with the spec as I think it is useful.  The semantics are 
tricky for people to understand so I was not all that concerned that the first 
draft was not perfect.  

I suspect some concrete examples will help.

John B.

On Jul 3, 2014, at 3:51 PM, Phil Hunt  wrote:

> 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 impersonating a whole person vs. having 
> delegate or scoped authority to act for someone.
> 
> Sorry if this is an old discussion.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> On Jul 3, 2014, at 12:20 PM, Mike Jones  wrote:
> 
>> 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.
>>  
>> -- Mike
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
>> Sent: Thursday, July 03, 2014 12:04 PM
>> To: Brian Campbell
>> Cc: oauth@ietf.org
>> Subject: 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: [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 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:44 AM
>> To: Vladimir Dzhuvinov
>> Cc: oauth@ietf.org
>> Subject: 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 
>> getting any real priority.
>> 
>> I have a few thoughts on 
>> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've 
>> been meaning to write dow

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

[Mike Jones]

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 OAuth Dynamic Client Registration Management has also been updated in the 
manner discussed at IETF 89 in London to be clear that not every server 
implementing Dynamic Client Registration will also implement this set of 
related management functions.

The updated specifications are available at:

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18

* http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-02

HTML formatted versions are also available at:

* https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-18.html

* 
https://self-issued.info/docs/draft-ietf-oauth-dyn-reg-management-02.html

-- Mike

P.S.  I also posted this notice at http://self-issued.info/?p=1248 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[internet-drafts]

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
  Michael B. Jones
  John Bradley
  Maciej Machulak
  Phil Hunt
Filename: draft-ietf-oauth-dyn-reg-management-02.txt
Pages   : 16
Date: 2014-07-03

Abstract:
   This specification defines methods for management of dynamic OAuth
   2.0 client registrations for use cases in which the properties of a
   registered client may need to be changed during the lifetime of the
   client.  Only some authorization servers supporting dynamic client
   registration will support these management methods.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg-management/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-management-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[internet-drafts]

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
  Michael B. Jones
  John Bradley
  Maciej Machulak
  Phil Hunt
Filename: draft-ietf-oauth-dyn-reg-18.txt
Pages   : 39
Date: 2014-07-03

Abstract:
   This specification defines mechanisms for dynamically registering
   OAuth 2.0 clients with authorization servers.  Registration requests
   send a set of desired client metadata values to the authorization
   server and the resulting registration responses return a client
   identifier to use at the authorization server and the client metadata
   values registered for the client.  The client can then use this
   registration information to communicate with the authorization server
   using the OAuth 2.0 protocol.  This specification also defines a set
   of common client metadata fields and values for clients to use during
   registration.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

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
no mention of privacy considerations.  I'm sure folks could generate great
stories about who accessing what causing privacy considerations to be
important.

Thanks & have a nice weekend!

-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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-token-exchange-00
*

Indecently, Bradely was the guy that suggested to me that the definitions
are reversed so I'm guessing he reads it the same way.

But Tony and Mike are authors of the two specs respectively in question so,
if they say that the definitions are aligned, they must be right.

As Phil said, there is a lot of historical confusion about the terms and I
think this conversation only underscores that confusion. A clean break with
new terms might be the way to go.



On Thu, Jul 3, 2014 at 1:51 PM, Phil Hunt  wrote:

> 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 impersonating a whole person vs. having
> delegate or scoped authority to act for someone.
>
> Sorry if this is an old discussion.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Jul 3, 2014, at 12:20 PM, Mike Jones 
> wrote:
>
>  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.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Anthony Nadalin
> *Sent:* Thursday, July 03, 2014 12:04 PM
> *To:* Brian Campbell
> *Cc:* oauth@ietf.org
> *Subject:* 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: [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 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:44 AM
> *To:* Vladimir Dzhuvinov
> *Cc:* oauth@ietf.org
> *Subject:* 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 getting any real priority.
>
> I have a few thoughts on
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
> been meaning to write down but haven't yet, so this seems like as good a
> time as any.
>
> I would really like to see a simpler request model that doesn't require
> the request to be JWT encoded.
>
> The draft mentions the potential confusion around On-Behalf-Of vs.
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the
> use of Act-As and On-Behalf-Of seem to be reversed from how they are
> defined in WS-Trust
>  (this MS
> FAQ  has less
> confusing wording). They should probably be aligned with that prior work to
> avoid further confusion. Or maybe making a clean break and introducing new
> terms would be better.
>
> I don't think the security_token_request grant type value is strictly
> legal per RFC 6749. The ABNF at
> http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but
> according to http://tools.ietf.org/html/rfc6749#section-4.5 extension
> grants need an absolute URI as the grant type value (there's no grant type
> registry so the URI is the only means of preventing collision).
>
>
>
>
>
>
>
>
>
>
> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious 

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

[Kathleen Moriarty]

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 -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 how we move forward on the following items will be necessary as
> well as the shepherd/chair okay to progress the drafts to IETF last call.
>  As an FYI, since it was requested that the drafts progress as a set, I may
> need to delay on which telechat the drafts get placed.  Essentially, the
> set requires a lot of reading and I'd like to give the IESG enough time to
> do reviews.
>
>
>
> 1. McGrew draft (applies to JWA)
>
>We are waiting on an updated version so that the JWA draft can refer to
> it as opposed to duplicating text from it.
>
>
>
> Mike>  I’d proposed specific changes to the authors in May and David
> McGrew had tentatively agreed with them and said that he’d produce an
> updated draft a few weeks ago.  This hasn’t happened yet.  I plan to stay
> engaged with this, including possibly producing a candidate draft to
> propose to the authors, if necessary.  (This won’t happen until sometime
> between the 4th and Toronto.)
>

OK, thanks for the status.

>
>
> 2. Alternate on text that applies to several of the drafts for the
> following:
>
>  Discussion on wording “or use a JSON parser that returns
>
>  only the lexically last duplicate member name, as specified
>
>  in Section 15.12 (The JSON Object) of ECMAScript 5.1
> [ECMAScript]”.
>
>
>
> Jim or others may have text suggestions.  This was discussed on list, but
> has not been resolved yet.
>
>
>
> Mike> I believe that it’s already unambiguous as worded, but would be
> open to even clearer wording, if someone supplies it.
>

OK, let's see if there are proposals or if Jim has a suggestion.

>
>
> 3. Use cases not met by current set of drafts
>
>  Documents do not meet all of the use cases laid out in the Use Cases
> document
>
>  Specifically section 5.8 since there is no key management for
>
>  MACs (5.8.1. – MAC based on ECDH-derived key)
>
> I'm not sure how this gets handled.  If it will be addressed in other
> drafts, let me know.
>
>
>
> Mike> This was issue #2 http://trac.tools.ietf.org/wg/jose/trac/ticket/2
> and was extensively discussed.  A formal consensus call on this was
> conducted by the chairs even prior to the attempt to re-open the issue by
> filing issue #2.  Jim’s resolution closing this was wontfix was “The
> working group has already considered this and has determined that it will
> not be addressed. Until a request for the feature comes in from a group
> such as the WebCrypto? group it will not be re-considered.”.
>
>
>
> That said, it’s well understood how this could be cleanly added in a
> backwards compatible way.  If a concrete need for this arises, I’d be glad
> to write up a quick draft, but since this is separable, I don’t believe
> that the possibility of doing this work in the future needs to have any
> impact on completing the drafts we already have, which intentionally
> address the most commonly occurring use cases.
>

OK, thank you.

>
>
> 4.  I don't recall seeing any internationalization considerations, is that
> something we need to worry about?
>
>
>
> Mike>  None of the 5 drafts define any strings intended for consumption by
> end-users, so I don’t think so.  Or if you prefer, I could explicitly say
> that, perhaps just in the JWT draft?  Your call…
>
No need then, if it comes up, I have an answer and that should be all I
need on this one.  Thanks.

>
>
> Nits/Comments for specific drafts:
>
>
>
> JWA:
>
> Security considerations section 8.2 Key Lifetimes
>
> Should there be a reference to NIST 800-57 to provide guidance on this
> topic.  If there is a better reference, that's fine too.  This is something
> that may get picked up on in other reviews.
>
>
>
> Mike> Will do
>
Thank you

>
>
> Thanks for reducing text by referring to other drafts for a good portion
> of the security considerations section.
>
>
>
> JWS:
>
> For typ and cty, the text could be more clear in the first paragraph
> sentence 2 and 4.  They read as if they are in conflict.   The specific
> usage is different in these sentences, but that is not made clear in the
> text.  It should just be a text adjustment.
>
>
>
> Mike>  Will do
>
Thank you

>
>
> Section 8: TLS requirements, second paragraph:
>
> For the second sentence, could you either include examples or a reference
> to where the reader can ascertain

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

[Mike Jones]

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 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 how we move forward on the following items will be necessary as well as 
the shepherd/chair okay to progress the drafts to IETF last call.  As an FYI, 
since it was requested that the drafts progress as a set, I may need to delay 
on which telechat the drafts get placed.  Essentially, the set requires a lot 
of reading and I'd like to give the IESG enough time to do reviews.

1. McGrew draft (applies to JWA)
   We are waiting on an updated version so that the JWA draft can refer to it 
as opposed to duplicating text from it.

Mike>  I’d proposed specific changes to the authors in May and David McGrew had 
tentatively agreed with them and said that he’d produce an updated draft a few 
weeks ago.  This hasn’t happened yet.  I plan to stay engaged with this, 
including possibly producing a candidate draft to propose to the authors, if 
necessary.  (This won’t happen until sometime between the 4th and Toronto.)

2. Alternate on text that applies to several of the drafts for the following:
 Discussion on wording “or use a JSON parser that returns
 only the lexically last duplicate member name, as specified
 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]”.

Jim or others may have text suggestions.  This was discussed on list, but has 
not been resolved yet.

Mike> I believe that it’s already unambiguous as worded, but would be open to 
even clearer wording, if someone supplies it.

3. Use cases not met by current set of drafts
 Documents do not meet all of the use cases laid out in the Use Cases 
document
 Specifically section 5.8 since there is no key management for
 MACs (5.8.1. – MAC based on ECDH-derived key)
I'm not sure how this gets handled.  If it will be addressed in other drafts, 
let me know.

Mike> This was issue #2 http://trac.tools.ietf.org/wg/jose/trac/ticket/2 and 
was extensively discussed.  A formal consensus call on this was conducted by 
the chairs even prior to the attempt to re-open the issue by filing issue #2.  
Jim’s resolution closing this was wontfix was “The working group has already 
considered this and has determined that it will not be addressed. Until a 
request for the feature comes in from a group such as the WebCrypto? group it 
will not be re-considered.”.

That said, it’s well understood how this could be cleanly added in a backwards 
compatible way.  If a concrete need for this arises, I’d be glad to write up a 
quick draft, but since this is separable, I don’t believe that the possibility 
of doing this work in the future needs to have any impact on completing the 
drafts we already have, which intentionally address the most commonly occurring 
use cases.

4.  I don't recall seeing any internationalization considerations, is that 
something we need to worry about?

Mike>  None of the 5 drafts define any strings intended for consumption by 
end-users, so I don’t think so.  Or if you prefer, I could explicitly say that, 
perhaps just in the JWT draft?  Your call…

Nits/Comments for specific drafts:

JWA:
Security considerations section 8.2 Key Lifetimes
Should there be a reference to NIST 800-57 to provide guidance on this topic.  
If there is a better reference, that's fine too.  This is something that may 
get picked up on in other reviews.

Mike> Will do

Thanks for reducing text by referring to other drafts for a good portion of the 
security considerations section.

JWS:
For typ and cty, the text could be more clear in the first paragraph sentence 2 
and 4.  They read as if they are in conflict.   The specific usage is different 
in these sentences, but that is not made clear in the text.  It should just be 
a text adjustment.

Mike>  Will do

Section 8: TLS requirements, second paragraph:
For the second sentence, could you either include examples or a reference to 
where the reader can ascertain appropriate appropriate cipher suites?  This may 
be tough to address, but the way the sentence is written, it sounds like a 
reference or a recommendation is needed.  Any ideas?

Mike>  I’d appreciate a specific reference.  I asked the TLS chairs for one 
yesterday, but haven’t heard back from them yet.

JWK:
Updates look good, thanks!

JWE:
Updates look good, thank you!

Oauth JWT: Sent to Oauth list

Mike> Thanks again for the thorough and useful reviews, Kathleen…

-- Mike

On Thu, Jul 3, 2014 at 2:31 PM,

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

[Kathleen Moriarty]

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
> unintended parties.  One way to achieve this is to use an encrypted JWT.
> Another way is to ensure that JWTs containing unencrypted privacy-sensitive
> information are only transmitted over encrypted channels or protocols, such
> as TLS.
>

Great, thanks!

>
>
> -- Mike
>
>
>
> *From:* Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
> *Sent:* Thursday, July 03, 2014 11:32 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
>
>
>
> 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 didn't catch that on the
> first review.
>
>
>
> On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones 
> wrote:
>
>
>
>
>
> *From:* Mike Jones
> *Sent:* Tuesday, July 01, 2014 6:11 PM
> *To:* j...@ietf.org
> *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth
> spec of five
>
>
>
> JOSE -30 and JWT -24 drafts have been posted incorporating improvements
> resulting from Kathleen Moriarty’s JWE review.  At this point, actions
> requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications
> have all been incorporated.  All changes in this release were strictly
> editorial in nature.
>
>
>
> The specifications are available at:
>
> · http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30
>
> ·
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30
>
> · http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30
>
> ·
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30
>
> · http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24
>
>
>
> HTML formatted versions are available at:
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html
>
>
>
> -- Mike
>
>
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1245 and
> as @selfissued.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> --
>
>
>
> Best regards,
>
> Kathleen
>



-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phil Hunt]

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 impersonating a whole person vs. having 
delegate or scoped authority to act for someone.

Sorry if this is an old discussion.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Jul 3, 2014, at 12:20 PM, Mike Jones  wrote:

> 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.
>  
> -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Thursday, July 03, 2014 12:04 PM
> To: Brian Campbell
> Cc: oauth@ietf.org
> Subject: 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: [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 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:44 AM
> To: Vladimir Dzhuvinov
> Cc: oauth@ietf.org
> Subject: 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 
> getting any real priority.
> 
> I have a few thoughts on 
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've 
> been meaning to write down but haven't yet, so this seems like as good a time 
> as any.
> 
> I would really like to see a simpler request model that doesn't require the 
> request to be JWT encoded.
> 
> The draft mentions the potential confusion around On-Behalf-Of vs. 
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
> of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
> WS-Trust (this MS FAQ has less confusing wording). They should probably be 
> aligned with that prior work to avoid further confusion. Or maybe making a 
> clean break and introducing new terms would be better.
> 
> I don't think the security_token_request grant type value is strictly legal 
> per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 
> would allow it but according to 
> http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an 
> absolute URI as the grant type value (there's no grant type registry so the 
> URI is the only means of preventing collision).
> 
>  
> 
>  
> 
>  
> 
>  
> 
> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov  
> wrote:
> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
> 
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
> 
> Thanks,
> 
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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 JWT.  Another way is 
to ensure that JWTs containing unencrypted privacy-sensitive information are 
only transmitted over encrypted channels or protocols, such as TLS.

-- Mike

From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com]
Sent: Thursday, July 03, 2014 11:32 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

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 didn't catch that on the first review.

On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:


From: Mike Jones
Sent: Tuesday, July 01, 2014 6:11 PM
To: j...@ietf.org
Subject: JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth spec of 
five

JOSE -30 and JWT -24 drafts have been posted incorporating improvements 
resulting from Kathleen Moriarty’s JWE review.  At this point, actions 
requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications have 
all been incorporated.  All changes in this release were strictly editorial in 
nature.

The specifications are available at:

• http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30

• http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30

• http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30

• http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30

• http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24

HTML formatted versions are available at:

• 
http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html

• 
http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html

• http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html

• 
http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html

• http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html

-- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1245 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Mike Jones]

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.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, July 03, 2014 12:04 PM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: 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: [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 
mailto:tony...@microsoft.com>> wrote:
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:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: 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 getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust (this MS 
FAQ has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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: [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 
mailto:tony...@microsoft.com>> wrote:
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:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: 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 getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust (this MS 
FAQ has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).





On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

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 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:44 AM
> *To:* Vladimir Dzhuvinov
> *Cc:* oauth@ietf.org
> *Subject:* 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 getting any real priority.
>
> I have a few thoughts on
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
> been meaning to write down but haven't yet, so this seems like as good a
> time as any.
>
> I would really like to see a simpler request model that doesn't require
> the request to be JWT encoded.
>
> The draft mentions the potential confusion around On-Behalf-Of vs.
> Impersonation Semantics. And it is confusing (to me anyway). In fact, the
> use of Act-As and On-Behalf-Of seem to be reversed from how they are
> defined in WS-Trust
>  (this MS
> FAQ  has less
> confusing wording). They should probably be aligned with that prior work to
> avoid further confusion. Or maybe making a clean break and introducing new
> terms would be better.
>
> I don't think the security_token_request grant type value is strictly
> legal per RFC 6749. The ABNF at
> http://tools.ietf.org/html/rfc6749#appendix-A.10 would allow it but
> according to http://tools.ietf.org/html/rfc6749#section-4.5 extension
> grants need an absolute URI as the grant type value (there's no grant type
> registry so the URI is the only means of preventing collision).
>
>
>
>
>
>
>
>
>
>
> On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
>
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
>
> Thanks,
>
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Anthony Nadalin]

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:44 AM
To: Vladimir Dzhuvinov
Cc: oauth@ietf.org
Subject: 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 getting 
any real priority.
I have a few thoughts on 
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've been 
meaning to write down but haven't yet, so this seems like as good a time as any.
I would really like to see a simpler request model that doesn't require the 
request to be JWT encoded.
The draft mentions the potential confusion around On-Behalf-Of vs. 
Impersonation Semantics. And it is confusing (to me anyway). In fact, the use 
of Act-As and On-Behalf-Of seem to be reversed from how they are defined in 
WS-Trust (this MS 
FAQ has less confusing 
wording). They should probably be aligned with that prior work to avoid further 
confusion. Or maybe making a clean break and introducing new terms would be 
better.
I don't think the security_token_request grant type value is strictly legal per 
RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10 would 
allow it but according to http://tools.ietf.org/html/rfc6749#section-4.5 
extension grants need an absolute URI as the grant type value (there's no grant 
type registry so the URI is the only means of preventing collision).






On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov 
mailto:vladi...@connect2id.com>> wrote:
Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
the on-behalf-of semantics? We've got a use case for that and I'm
curious if someone has used it in practice.

http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00

Thanks,

Vladimir
--
Vladimir Dzhuvinov mailto:vladi...@connect2id.com>>
Connect2id Ltd.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

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 how we move forward on the following items will be necessary as
well as the shepherd/chair okay to progress the drafts to IETF last call.
 As an FYI, since it was requested that the drafts progress as a set, I may
need to delay on which telechat the drafts get placed.  Essentially, the
set requires a lot of reading and I'd like to give the IESG enough time to
do reviews.

1. McGrew draft (applies to JWA)
   We are waiting on an updated version so that the JWA draft can refer to
it as opposed to duplicating text from it.

2. Alternate on text that applies to several of the drafts for the
following:
 Discussion on wording “or use a JSON parser that returns
 only the lexically last duplicate member name, as specified
 in Section 15.12 (The JSON Object) of ECMAScript 5.1
[ECMAScript]”.

Jim or others may have text suggestions.  This was discussed on list, but
has not been resolved yet.

3. Use cases not met by current set of drafts
 Documents do not meet all of the use cases laid out in the Use Cases
document
 Specifically section 5.8 since there is no key management for
 MACs (5.8.1. – MAC based on ECDH-derived key)
I'm not sure how this gets handled.  If it will be addressed in other
drafts, let me know.

4.  I don't recall seeing any internationalization considerations, is that
something we need to worry about?


Nits/Comments for specific drafts:

JWA:
Security considerations section 8.2 Key Lifetimes
Should there be a reference to NIST 800-57 to provide guidance on this
topic.  If there is a better reference, that's fine too.  This is something
that may get picked up on in other reviews.

Thanks for reducing text by referring to other drafts for a good portion of
the security considerations section.

JWS:
For typ and cty, the text could be more clear in the first paragraph
sentence 2 and 4.  They read as if they are in conflict.   The specific
usage is different in these sentences, but that is not made clear in the
text.  It should just be a text adjustment.

Section 8: TLS requirements, second paragraph:
For the second sentence, could you either include examples or a reference
to where the reader can ascertain appropriate appropriate cipher suites?
 This may be tough to address, but the way the sentence is written, it
sounds like a reference or a recommendation is needed.  Any ideas?

JWK:
Updates look good, thanks!

JWE:
Updates look good, thank you!

Oauth JWT: Sent to Oauth list



On Thu, Jul 3, 2014 at 2:31 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> 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 didn't catch that on the
> first review.
>
>
> On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones 
> wrote:
>
>>
>>
>>
>>
>> *From:* Mike Jones
>> *Sent:* Tuesday, July 01, 2014 6:11 PM
>> *To:* j...@ietf.org
>> *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on
>> fifth spec of five
>>
>>
>>
>> JOSE -30 and JWT -24 drafts have been posted incorporating improvements
>> resulting from Kathleen Moriarty’s JWE review.  At this point, actions
>> requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications
>> have all been incorporated.  All changes in this release were strictly
>> editorial in nature.
>>
>>
>>
>> The specifications are available at:
>>
>> ·
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30
>>
>> ·
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30
>>
>> · http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30
>>
>> ·
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30
>>
>> · http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24
>>
>>
>>
>> HTML formatted versions are available at:
>>
>> ·
>> http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html
>>
>> ·
>> http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html
>>
>> ·
>> http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html
>>
>> ·
>> http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html
>>
>> ·
>> http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html
>>
>>
>>
>> -- Mike
>>
>>
>>
>> P.S.  This notice was also posted at http://self-issued.info/?p=1245 and
>> as @selfissued.
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailma

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

[Brian Campbell]

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 getting any real priority.

I have a few thoughts on
http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00 which I've
been meaning to write down but haven't yet, so this seems like as good a
time as any.

I would really like to see a simpler request model that doesn't require the
request to be JWT encoded.

The draft mentions the potential confusion around On-Behalf-Of vs.
Impersonation Semantics. And it is confusing (to me anyway). In fact, the
use of Act-As and On-Behalf-Of seem to be reversed from how they are
defined in WS-Trust
 (this MS FAQ
 has less confusing
wording). They should probably be aligned with that prior work to avoid
further confusion. Or maybe making a clean break and introducing new terms
would be better.

I don't think the security_token_request grant type value is strictly legal
per RFC 6749. The ABNF at http://tools.ietf.org/html/rfc6749#appendix-A.10
would allow it but according to
http://tools.ietf.org/html/rfc6749#section-4.5 extension grants need an
absolute URI as the grant type value (there's no grant type registry so the
URI is the only means of preventing collision).










On Fri, Jun 27, 2014 at 6:07 AM, Vladimir Dzhuvinov  wrote:

> Has anyone implemented the OAuth 2.0 Token exchange draft, in particular
> the on-behalf-of semantics? We've got a use case for that and I'm
> curious if someone has used it in practice.
>
> http://tools.ietf.org/html/draft-jones-oauth-token-exchange-00
>
> Thanks,
>
> Vladimir
> --
> Vladimir Dzhuvinov 
> Connect2id Ltd.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kathleen Moriarty]

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 didn't catch that on the
first review.


On Tue, Jul 1, 2014 at 9:11 PM, Mike Jones 
wrote:

>
>
>
>
> *From:* Mike Jones
> *Sent:* Tuesday, July 01, 2014 6:11 PM
> *To:* j...@ietf.org
> *Subject:* JOSE -30 and JWT -24 drafts incorporating AD feedback on fifth
> spec of five
>
>
>
> JOSE -30 and JWT -24 drafts have been posted incorporating improvements
> resulting from Kathleen Moriarty’s JWE review.  At this point, actions
> requested in her reviews of the JWS, JWE, JWK, JWA, and JWT specifications
> have all been incorporated.  All changes in this release were strictly
> editorial in nature.
>
>
>
> The specifications are available at:
>
> · http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-30
>
> ·
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-30
>
> · http://tools.ietf.org/html/draft-ietf-jose-json-web-key-30
>
> ·
> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-30
>
> · http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-24
>
>
>
> HTML formatted versions are available at:
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-signature-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-key-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-30.html
>
> ·
> http://self-issued.info/docs/draft-ietf-oauth-json-web-token-24.html
>
>
>
> -- Mike
>
>
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1245 and
> as @selfissued.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda requests, please

[Kathleen Moriarty]

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
well.  We should know more n the timing soon.

I do plan to get the AD reviews out soon for the Oauth drafts that were to
follow the first set.


On Thu, Jul 3, 2014 at 1:30 PM, 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 from the IESG on the assertion bundle but I
> trust Mike can handle it, if something requiring agenda time does surface
> between now and then.
>
>
> On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi all,
>>
>> by next Monday we have to post a draft agenda for the upcoming IETF
>> meeting.
>>
>> If you would like to talk about a specific topic, please let us know.
>>
>> My impression regarding the status of our work is the following:
>>
>>
>>  Current WG items ---
>>
>> * Dynamic Client Registration
>>
>> We are waiting for an update but the document could be completed by the
>> IETF meeting. ==> no presentation time.
>>
>> * JWT
>>
>> Currently in IESG processing and a new draft update has just been
>> submitted. ==> no presentation time (#)
>>
>> * Assertion Bundle
>>
>> Currently in IESG processing. ==> no presentation time (#)
>>
>> * Dynamic Client Registration Management Protocol
>>
>> We had a discussion about this work at the last IETF meeting and the
>> path forward looked somewhat difficult. Nothing has happened since that
>> time and I am inclined to remove it from the list of WG items.
>>
>> * Proof-of-Possession Security
>>
>> We have several new documents and I hope we can turn into working group
>> items already before the meeting. We would then use the meeting time to
>> discuss open issues.
>>
>> #: No presentation time unless some challenging comments from the IESG
>> surface.
>>
>>  Proposed New WG items ---
>>
>> I would also like to put the following items on the agenda.
>>
>> * Token Introspection
>>
>> * draft-sakimura-oauth-tcse-03
>>
>>  Other items ---
>>
>> Phil might want to bring up this item since it was discussed on the
>> list: draft-hunt-oauth-v2-user-a4c
>>
>> Other ideas/suggestions?
>>
>> Ciao
>> Hannes
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 

Best regards,
Kathleen
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda requests, please

[Bill Mills]

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 from the  IESG on the assertion bundle but I 
trust Mike can handle it, if something requiring agenda time does surface 
between now and then.




On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig  
wrote:

Hi all,
>
>by next Monday we have to post a draft agenda for the upcoming IETF
>meeting.
>
>If you would like to talk about a specific topic, please let us know.
>
>My impression regarding the status of our work is the following:
>
>
> Current WG items ---
>
>* Dynamic Client Registration
>
>We are waiting for an update but the document could be completed by the
>IETF meeting. ==> no presentation time.
>
>* JWT
>
>Currently in IESG processing and a new draft update has just been
>submitted. ==> no presentation time (#)
>
>* Assertion Bundle
>
>Currently in IESG processing. ==> no presentation time (#)
>
>* Dynamic Client Registration Management Protocol
>
>We had a discussion about this work at the last IETF meeting and the
>path forward looked somewhat difficult. Nothing has happened since that
>time and I am inclined to remove it from the list of WG items.
>
>* Proof-of-Possession Security
>
>We have several new documents and I hope we can turn into working group
>items already before the meeting. We would then use the meeting time to
>discuss open issues.
>
>#: No presentation time unless some challenging comments from the IESG
>surface.
>
> Proposed New WG items ---
>
>I would also like to put the following items on the agenda.
>
>* Token Introspection
>
>* draft-sakimura-oauth-tcse-03
>
> Other items ---
>
>Phil might want to bring up this item since it was discussed on the
>list: draft-hunt-oauth-v2-user-a4c
>
>Other ideas/suggestions?
>
>Ciao
>Hannes
>
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda requests, please

[Justin Richer]

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:

> 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 now and then.
> 
> 
> On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig  
> wrote:
> Hi all,
> 
> by next Monday we have to post a draft agenda for the upcoming IETF
> meeting.
> 
> If you would like to talk about a specific topic, please let us know.
> 
> My impression regarding the status of our work is the following:
> 
> 
>  Current WG items ---
> 
> * Dynamic Client Registration
> 
> We are waiting for an update but the document could be completed by the
> IETF meeting. ==> no presentation time.
> 
> * JWT
> 
> Currently in IESG processing and a new draft update has just been
> submitted. ==> no presentation time (#)
> 
> * Assertion Bundle
> 
> Currently in IESG processing. ==> no presentation time (#)
> 
> * Dynamic Client Registration Management Protocol
> 
> We had a discussion about this work at the last IETF meeting and the
> path forward looked somewhat difficult. Nothing has happened since that
> time and I am inclined to remove it from the list of WG items.
> 
> * Proof-of-Possession Security
> 
> We have several new documents and I hope we can turn into working group
> items already before the meeting. We would then use the meeting time to
> discuss open issues.
> 
> #: No presentation time unless some challenging comments from the IESG
> surface.
> 
>  Proposed New WG items ---
> 
> I would also like to put the following items on the agenda.
> 
> * Token Introspection
> 
> * draft-sakimura-oauth-tcse-03
> 
>  Other items ---
> 
> Phil might want to bring up this item since it was discussed on the
> list: draft-hunt-oauth-v2-user-a4c
> 
> Other ideas/suggestions?
> 
> Ciao
> Hannes
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Agenda requests, please

[Brian Campbell]

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 now and then.


On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig  wrote:

> Hi all,
>
> by next Monday we have to post a draft agenda for the upcoming IETF
> meeting.
>
> If you would like to talk about a specific topic, please let us know.
>
> My impression regarding the status of our work is the following:
>
>
>  Current WG items ---
>
> * Dynamic Client Registration
>
> We are waiting for an update but the document could be completed by the
> IETF meeting. ==> no presentation time.
>
> * JWT
>
> Currently in IESG processing and a new draft update has just been
> submitted. ==> no presentation time (#)
>
> * Assertion Bundle
>
> Currently in IESG processing. ==> no presentation time (#)
>
> * Dynamic Client Registration Management Protocol
>
> We had a discussion about this work at the last IETF meeting and the
> path forward looked somewhat difficult. Nothing has happened since that
> time and I am inclined to remove it from the list of WG items.
>
> * Proof-of-Possession Security
>
> We have several new documents and I hope we can turn into working group
> items already before the meeting. We would then use the meeting time to
> discuss open issues.
>
> #: No presentation time unless some challenging comments from the IESG
> surface.
>
>  Proposed New WG items ---
>
> I would also like to put the following items on the agenda.
>
> * Token Introspection
>
> * draft-sakimura-oauth-tcse-03
>
>  Other items ---
>
> Phil might want to bring up this item since it was discussed on the
> list: draft-hunt-oauth-v2-user-a4c
>
> Other ideas/suggestions?
>
> Ciao
> Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Bill Mills]

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 client ID 
would fail.

With DynReg that client could generate a nonce and include it in a dynamically 
registered client ID and then the credential could be bound to that specific 
software instance.

A 3rd possibility is multiple clients on a device sharing the same auth 
context, in which case they all use the same library perhaps and so several 
installed apps all would share the same "client id" from the servers 
perspective (the one for the auth API) but they might each get different scopes.


On Thursday, July 3, 2014 9:28 AM, Sergey Beryozkin  
wrote:
 


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 too if you know
> you need to.
>
What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).

What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.

+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.

When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.

Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?

So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.

During the subsequent refresh token grant request we have "client id + 
refresh token" as a client instance.

I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:

Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.

Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome

Thanks, Sergey







> -bill
>
>
> On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
>  wrote:
>
>
> 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 token.
> And when the client uses a refresh token grant.
>
> Was it really about a refresh token grant where the incoming client id
> and refresh token pair can uniquely identify the actual client instance
> ? That would make sense.
>
> Something else I'd like to clarify.
> John mentions a refresh token is created at the authorization grant
> initialization time. Would it make any difference, as far as the
> security properties of a grant are concerned, if refresh token was only
> created at a grant to access token exchange point of time ?
>
> Thanks, Sergey
>
> On 27/06/14 19:21, John Bradley wrote:
>  > Inline
>  >
>  > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  
>  > >> wrote:
>  >
>  >> Hi John,
>  >> Thank you for your reply. Would appreciate if you consider my inline
>  >> comments below and respond again!
>  >> R,
>  >> Madjid
>  >> *From:*John Bradley [mailto:ve7...@ve7jtb.com
> ]
>  >> *Sent:*Wednesday, June 25, 2014 5:56 PM
>  >> *To:*Madjid Nakhjiri
>  >> *Cc:*oauth@ietf.org   >
>  >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>  >> In 3.3 It is saying that the refresh token is a secret that the
>  >> Authorization server has bound to the client_id, that the
>  >> Authorization se

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

[Sergey Beryozkin]

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 too if you know
you need to.

What exactly is a 'client instance' when we talk about having a single 
client id registration, with the id shared between multiple devices 
(which is what I believe this thread started from).


What I understood, as far as the authorization service is concerned, a 
'client instance' for AS is a combination of a client id + code grant.


+ (optional) refresh token (as was mentioned earlier). But it appears to 
me a client instance can be uniquely identified by two values only 
without a refresh token.


When a user authorizes a given device and gets a grant code and enters 
it into the device securely we have a 'client instance' ready to get the 
tokens, with that device (client instance) using a client id and the 
grant code to get an access token and a refresh token.


Lets say it sends a "client_id=1&code=2" sequence to get the tokens.
A client id + a code value constitutes a client instance, because a code 
would be unique per every authorization, right ?


So the service will return an access token + refresh token to the 
device. Refresh Token could've been associated with a record containing 
a client id + grant code info earlier or at the moment the code is 
exchanged for an access token.


During the subsequent refresh token grant request we have "client id + 
refresh token" as a client instance.


I'm not sure what exactly I'd like to ask here :-), but I wonder if the 
above sounds right, then I guess I'd like to conclude that when we talk 
about the authorization code grant then a refresh token is not the only 
key that uniquely identifies a client instance:


Initially it is a client id + code grant, a refresh token does not offer 
an extra uniqueness at the point of the client device requesting an 
access token with a code. Refresh token only starts acting as the key 
client instance identifier at a refresh token grant time.


Sorry for a long email, I'm very likely missing something, so any 
clarifications will be welcome


Thanks, Sergey








-bill


On Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin
 wrote:


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 token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id
and refresh token pair can uniquely identify the actual client instance
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant
initialization time. Would it make any difference, as far as the
security properties of a grant are concerned, if refresh token was only
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
 > Inline
 >
 > On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri mailto:m.nakhj...@samsung.com>
 > >> wrote:
 >
 >> Hi John,
 >> Thank you for your reply. Would appreciate if you consider my inline
 >> comments below and respond again!
 >> R,
 >> Madjid
 >> *From:*John Bradley [mailto:ve7...@ve7jtb.com
]
 >> *Sent:*Wednesday, June 25, 2014 5:56 PM
 >> *To:*Madjid Nakhjiri
 >> *Cc:*oauth@ietf.org  >
 >> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
 >> In 3.3 It is saying that the refresh token is a secret that the
 >> Authorization server has bound to the client_id, that the
 >> Authorization server effectively uses to differentiate between
 >> instances of that client_id.
 >> Madjid>>If I have 10,000s of devices, each with an instance of the
 >> OAUTH client, but they are all using the same client ID, how would the
 >> server know which token to use for what client? unless when I am
 >> creating a token, I also include something that uniquely identifies
 >> each instance? Don’t I have to use SOMETHING that is unique to that
 >> instance (user grant/ID?)?
 > When the grant is issued you create and store a refresh token which is
 > effectively the identifier for that instance/grant combination.
 > When it comes back on a request to the token endpoint you look up the
 > grants associated with it.  You also hack that the client_id sent in
 > the request matches to detect errors mostly)
 >
 >> When the refresh token is generated, it can be stored in a table with
 >> the client_id and the information about the grant.  You could also do
 >> i

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

[Phil Hunt]

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 sure all of these are RESTful crud 
operations. They feel process/rpc oriented. 

It just seems to me the use case/requirements need work first. 

Phil

> On Jul 3, 2014, at 2:46, Hannes Tschofenig  wrote:
> 
> 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, Brian Campbell wrote:
>> Having difficulty finding consensus around a solution isn’t the same
>> thing as lack of interest in a solution. I think it would be very
>> premature to remove the Dynamic Client Registration Management
>> Protocol from the list of WG items.
>> 
>> On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig
>>  wrote:
>>> 
>>> * Dynamic Client Registration Management Protocol
>>> 
>>> We had a discussion about this work at the last IETF meeting and the
>>> path forward looked somewhat difficult. Nothing has happened since that
>>> time and I am inclined to remove it from the list of WG items.
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Bill Mills]

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 Thursday, July 3, 2014 4:33 AM, Sergey Beryozkin  
wrote:
 


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 token.
And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.

Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?

Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:
> Inline
>
> On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri  > wrote:
>
>> Hi John,
>> Thank you for your reply. Would appreciate if you consider my inline
>> comments below and respond again!
>> R,
>> Madjid
>> *From:*John Bradley [mailto:ve7...@ve7jtb.com]
>> *Sent:*Wednesday, June 25, 2014 5:56 PM
>> *To:*Madjid Nakhjiri
>> *Cc:*oauth@ietf.org 
>> *Subject:*Re: [OAUTH-WG] refresh tokens and client instances
>> In 3.3 It is saying that the refresh token is a secret that the
>> Authorization server has bound to the client_id, that the
>> Authorization server effectively uses to differentiate between
>> instances of that client_id.
>> Madjid>>If I have 10,000s of devices, each with an instance of the
>> OAUTH client, but they are all using the same client ID, how would the
>> server know which token to use for what client? unless when I am
>> creating a token, I also include something that uniquely identifies
>> each instance? Don’t I have to use SOMETHING that is unique to that
>> instance (user grant/ID?)?
> When the grant is issued you create and store a refresh token which is
> effectively the identifier for that instance/grant combination.
> When it comes back on a request to the token endpoint you look up the
> grants associated with it.   You also hack that the client_id sent in
> the request matches to detect errors mostly)
>
>> When the refresh token is generated, it can be stored in a table with
>> the client_id and the information about the grant.   You could also do
>> it statelesly by creating a signed object as the refresh token.
>> Madjid>>agreed, but for the signed object to be self-sustained, again
>> would I not need something beyond a “population” client_ID? Are we
>> prescriptive what “information about the grant” is?
> You would be creating a bearer token as long as the AS signs it you can
> put whatever grant grant info you like in it, that is implementation
> specific.  It  could be a list of the scopes granted and the subject.
>> The spec is silent on the exact programming method that the
>> Authorization server uses.
>> Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
>> that prescribe token calculation (e.g. hash function, parameters, etc)?
>
> You can look at JOSE and JWT for a way to create tokens
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token
>> In 3.7 Deployment independent describes using the same client_id
>> across multiple instances of a native client, or multiple instances of
>> a Java Script client running in a browsers with the same callback uri.
>> Since the publishing of this RFC we have also developed a spec for
>> dynamic client registration so it is possible to give every native
>> client it's own client_id and secret making them confidential clients.
>> Madjid>>I would need to look at those specs, however, I thought that
>> the “confidential client” designation has to do with the client
>> ability to hold secrets and perform a-by-server-acceptable
>> authentication. Does dynamic client registration affect client’s
>> ability in that aspect?
>
> Yes it doesn't require the secret to be in the downloaded instance of
> the native app.  It can be populated at first run, changing it from
> public to confidential.
> Confidential is not just for web servers any more.
>> There is also a middle ground some people take by doing a proof of
>> possession for code in native applications to prevent the interception
>> of responses to the client by malicious applications on the device.
>> https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
>> John B.
>> On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri > > wrote:
>>
>>
>> Hi all,
>> I am n

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

[Sergey Beryozkin]

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 token.

And when the client uses a refresh token grant.

Was it really about a refresh token grant where the incoming client id 
and refresh token pair can uniquely identify the actual client instance 
? That would make sense.


Something else I'd like to clarify.
John mentions a refresh token is created at the authorization grant 
initialization time. Would it make any difference, as far as the 
security properties of a grant are concerned, if refresh token was only 
created at a grant to access token exchange point of time ?


Thanks, Sergey

On 27/06/14 19:21, John Bradley wrote:

Inline

On Jun 27, 2014, at 1:24 PM, Madjid Nakhjiri mailto:m.nakhj...@samsung.com>> wrote:


Hi John,
Thank you for your reply. Would appreciate if you consider my inline
comments below and respond again!
R,
Madjid
*From:*John Bradley [mailto:ve7...@ve7jtb.com]
*Sent:*Wednesday, June 25, 2014 5:56 PM
*To:*Madjid Nakhjiri
*Cc:*oauth@ietf.org 
*Subject:*Re: [OAUTH-WG] refresh tokens and client instances
In 3.3 It is saying that the refresh token is a secret that the
Authorization server has bound to the client_id, that the
Authorization server effectively uses to differentiate between
instances of that client_id.
Madjid>>If I have 10,000s of devices, each with an instance of the
OAUTH client, but they are all using the same client ID, how would the
server know which token to use for what client? unless when I am
creating a token, I also include something that uniquely identifies
each instance? Don’t I have to use SOMETHING that is unique to that
instance (user grant/ID?)?

When the grant is issued you create and store a refresh token which is
effectively the identifier for that instance/grant combination.
When it comes back on a request to the token endpoint you look up the
grants associated with it.   You also hack that the client_id sent in
the request matches to detect errors mostly)


When the refresh token is generated, it can be stored in a table with
the client_id and the information about the grant.   You could also do
it statelesly by creating a signed object as the refresh token.
Madjid>>agreed, but for the signed object to be self-sustained, again
would I not need something beyond a “population” client_ID? Are we
prescriptive what “information about the grant” is?

You would be creating a bearer token as long as the AS signs it you can
put whatever grant grant info you like in it, that is implementation
specific.  It  could be a list of the scopes granted and the subject.

The spec is silent on the exact programming method that the
Authorization server uses.
Madjid>>Are there any other specs in IETF or elsewhere (OASIS, etc?)
that prescribe token calculation (e.g. hash function, parameters, etc)?


You can look at JOSE and JWT for a way to create tokens
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token

In 3.7 Deployment independent describes using the same client_id
across multiple instances of a native client, or multiple instances of
a Java Script client running in a browsers with the same callback uri.
Since the publishing of this RFC we have also developed a spec for
dynamic client registration so it is possible to give every native
client it's own client_id and secret making them confidential clients.
Madjid>>I would need to look at those specs, however, I thought that
the “confidential client” designation has to do with the client
ability to hold secrets and perform a-by-server-acceptable
authentication. Does dynamic client registration affect client’s
ability in that aspect?


Yes it doesn't require the secret to be in the downloaded instance of
the native app.  It can be populated at first run, changing it from
public to confidential.
Confidential is not just for web servers any more.

There is also a middle ground some people take by doing a proof of
possession for code in native applications to prevent the interception
of responses to the client by malicious applications on the device.
https://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse/
John B.
On Jun 25, 2014, at 8:06 PM, Madjid Nakhjiri mailto:m.nakhj...@samsung.com>> wrote:


Hi all,
I am new to OAUTH list and OAUTH, so apologies if this is very off-topic.
I am evaluating an OAUTH 2.0 implementation that is done based on bare
bone base OAUTH2.0 RFC. From what I understand, many (or some) client
implementations use a “global ID/secret” pair for all instances of the
client.  Looking at RFC 6819 and there seem to be a whole page on this
topic, if I understand it correctly. So questions:
1)Section 3.7 talks about deployment-independent versus deployment
specific client IDs. I am guessing “deployment-independent” refers to
w

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

[Hannes Tschofenig]

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, Brian Campbell wrote:
> Having difficulty finding consensus around a solution isn’t the same
> thing as lack of interest in a solution. I think it would be very
> premature to remove the Dynamic Client Registration Management
> Protocol from the list of WG items.
> 
> On Wed, Jul 2, 2014 at 8:06 AM, Hannes Tschofenig
>  wrote:
>>
>> * Dynamic Client Registration Management Protocol
>>
>> We had a discussion about this work at the last IETF meeting and the
>> path forward looked somewhat difficult. Nothing has happened since that
>> time and I am inclined to remove it from the list of WG items.



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth