Subject: [OAUTH-WG] Rechartering

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 19 Oct 2011 22:08:30 -0700

Hi all, 

in preparation of the upcoming IETF meeting Barry and I would like to start a re-chartering discussion.  We both are currently attending the Internet Identity Workshop and so we had the chance to solicit input from the participants. This should serve as a discussion starter. 

Potential future OAuth charter items (in random order): 

----------------

1) Dynamic Client Registration Protocol

Available document: 
http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/

2) Token Revocation

Available document: 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/

3) UMA 

Available document: 
http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

4) Client Instance Extension

Available document:
http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt

5) XML Encoding

Available document:
http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt

6) JSON Web Token

Available document:
http://tools.ietf.org/html/draft-jones-json-web-token-05

7) JSON Web Token (JWT) Bearer Profile

Available document: 
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00

8) User Experience Extension

Available document:
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

9) Request by Reference

Available document: 
http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00

10) Simple Web Discovery

Available document: 
http://tools.ietf.org/html/draft-jones-simple-web-discovery-00

----------------

We have the following questions: 

a) Are you interested in any of the above-listed items? (as a reviewer, co-author, implementer, or someone who would like to deploy). It is also useful to know if you think that we shouldn't work on a specific item. 

b) Are there other items you would like to see the group working on?

Note: In case your document is expired please re-submit it. 

Ciao
Hannes & Barry

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 19 Oct 2011 22:55:47 -0700

No-brainer, low-hanging-fruit:

2) Token Revocation

Don't see the point, but simple enough not to care if plenty of others want to see it included:

Now for the objectionable...

This is premature standardization and must be deferred until we have enough real world experience and real world requirements. Since we don't have enough interoperable web protocols (e.g. sharing photos), there is little need for dynamic client registration at this point. Doing this wrong would be extremely costly. We have tried this multiple times with OAuth 1.0 and failed because there was no one at the table shipping real-world products that needed this functionality.

3) UMA

This is big enough, and complex enough, for its own working group and list (which I thought it already had elsewhere). Does not belong here. It is a layer above OAuth, not part of it.

6) JSON Web Token

This is big enough for its own working group and list. It also overlaps with the new JSON signature working group recently created.

10) Simple Web Discovery

First, this clearly does not belong here. This is a classic Application area item, and should really be raised in the application area general WG. I'd also point out that the IESG has recently approved the publication of host-meta as a proposed standard and the latest version includes a JSON flavor which makes this work redundant.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Wednesday, October 19, 2011 10:09 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Rechartering
> 
> Hi all,
> 
> in preparation of the upcoming IETF meeting Barry and I would like to start a
> re-chartering discussion.  We both are currently attending the Internet
> Identity Workshop and so we had the chance to solicit input from the
> participants. This should serve as a discussion starter.
> 
> a) Are you interested in any of the above-listed items? (as a reviewer, co-
> author, implementer, or someone who would like to deploy). It is also useful
> to know if you think that we shouldn't work on a specific item.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 20 Oct 2011 13:49:26 +0000

If scoped right I don't see any issues with any of these proposed items fitting into this WG, the question will be do we have the band width to work on all these items, as some are big and some are fairly small and contained. May have to have some prioritized list of where people think these fit. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 19, 2011 10:09 PM
To: OAuth WG
Subject: [OAUTH-WG] Rechartering

Hi all, 

----------------

Available document: 

2) Token Revocation

Available document: 

3) UMA 

Available document: 

Available document:

5) XML Encoding

Available document:

6) JSON Web Token

Available document:

Available document: 

Available document:

9) Request by Reference

Available document: 

10) Simple Web Discovery

Available document: 

----------------

Ciao
Hannes & Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Oct 2011 12:05:06 -0400

> do we have the band width to work on all these items, as some are
> big and some are fairly small and contained. May have to have some
> prioritized list of where people think these fit.

Yes, exactly.  And one of the things we'd like to hear from all of you
is what your priorities are... how you would prioritize the list.

Barry, chair-like object

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 20 Oct 2011 16:30:40 +0000

I think it will be true that the whole working group won't be focusing on all documents at the same time, much in the same way that different subsets of our current WG have focused on things like the security document or SAML bindings. In this fashion, I believe we'll be able to pull expertise from different sectors to produce a family of documents that live in an ecosystem around OAuth. 

For many of these documents, even though they're not directly OAuth pieces (like JWT), but where else should they live? This may not be The Way That IETF Does It (I'm honestly not sure), but in my opinion, as long as each document has a dedicated editor and at least some interaction/support with the group we can handle many of these smaller items.

 -- Justin
________________________________________
From: [email-masked] [[email-masked]] on behalf of Barry Leiba [[email-masked]]
Sent: Thursday, October 20, 2011 12:05 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Barry, chair-like object

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Oct 2011 10:18:41 -0700

Certainly not everyone needs to pay attention to everything. We are, however, trying to determine whether there is a critical mass of interested persons for a given item in terms of reviews, document authors, implementers, and deployers. 

I do not see a problem at all with working on JWT within the OAuth working group. I thought that we had already decided in the past that the JSON signature & encryption work would go into JOES (earlier WOES) and the home for JWT is the OAuth working group. The area directors may have a different opinion but for the moment this is my working assumption. 

Ciao
Hannes

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Oct 2011 10:40:08 -0700

Who is "we had already decided"? This was not discussed on this list.

EHL

> Sent: Thursday, October 20, 2011 10:19 AM
> To: Richer, Justin P.
> Cc: OAuth WG; Barry Leiba
> Certainly not everyone needs to pay attention to everything. We are,
> however, trying to determine whether there is a critical mass of interested
> persons for a given item in terms of reviews, document authors,
> implementers, and deployers.
> 
> I do not see a problem at all with working on JWT within the OAuth working
> group. I thought that we had already decided in the past that the JSON
> signature & encryption work would go into JOES (earlier WOES) and the
> home for JWT is the OAuth working group. The area directors may have a
> different opinion but for the moment this is my working assumption.
> 
> Ciao
> Hannes
> 
> 
> > I think it will be true that the whole working group won't be focusing on all
> documents at the same time, much in the same way that different subsets of
> our current WG have focused on things like the security document or SAML
> bindings. In this fashion, I believe we'll be able to pull expertise from
> different sectors to produce a family of documents that live in an ecosystem
> around OAuth.
> >
> > For many of these documents, even though they're not directly OAuth
> pieces (like JWT), but where else should they live? This may not be The Way
> That IETF Does It (I'm honestly not sure), but in my opinion, as long as each
> document has a dedicated editor and at least some interaction/support with
> the group we can handle many of these smaller items.
> >
> > -- Justin
> >> do we have the band width to work on all these items, as some are big
> >> and some are fairly small and contained. May have to have some

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Oct 2011 10:57:56 -0700

This is not how the IETF, or for that matter, any standards body operates. Working groups must be focused with a clearly defined purpose. For example, JWT is a large enough effort and clear enough to form a working group today - just go ahead and propose it. JWT has OAuth binding but it is not part of OAuth. JWT to OAuth is what WebDAV is to HTTP.

It is not enough to have critical mass for each document if there isn't a significant overlap in audience across each. Trying to do too much at the same times creates list noise and really forces those with day jobs not dedicated to standards to leave the WG.

Bundling efforts makes sense when they are small enough and can be finished in a short period of time. Some of these documents can also live on the list but not become official WG documents. Take a look at HTTPbis - they have a clear charter and set of documents but the list is discussing about a dozen of other individual submissions, some from the editors and chair of the WG, without any problem or heavy handed process.

EHL

> Of Richer, Justin P.
> Sent: Thursday, October 20, 2011 9:31 AM
> To: Barry Leiba; OAuth WG
> Yes, exactly.  And one of the things we'd like to hear from all of you is what
> your priorities are... how you would prioritize the list.
> 
> Barry, chair-like object

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Oct 2011 19:11:42 +0000

Thanks, Hannes.  Here's my prioritized list of new work:

1.  JSON Web Token (JWT)
2.  Simple Web Discovery (SWD)
3.  JSON Web Token (JWT) Bearer Token Profile
4.  Token Revocation

My prioritized list of existing work items to complete after the core and bearer specs are:

A.  Assertions Specification
B.  SAML Bearer Token Profile

I am ambivalent about whether the working group takes on most of the other work items.

Responding to Eran's comments on SWD versus host-meta, these specs have significantly different goals and use substantially different mechanisms with different privacy characteristics.  Also, if you compare the relative complexity of the example at http://tools.ietf.org/html/draft-hammer-hostmeta-17#appendix-A versus the example at http://tools.ietf.org/html/draft-jones-simple-web-discovery-01#section-1, you can see why SWD was chosen for use in OpenID Connect to discover OAuth authorization and resource server endpoints.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, October 19, 2011 10:09 PM
To: OAuth WG
Subject: [OAUTH-WG] Rechartering

Hi all, 

----------------

Available document: 

2) Token Revocation

Available document: 

3) UMA 

Available document: 

Available document:

5) XML Encoding

Available document:

6) JSON Web Token

Available document:

Available document: 

Available document:

9) Request by Reference

Available document: 

10) Simple Web Discovery

Available document: 

----------------

Ciao
Hannes & Barry

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Oct 2011 12:42:26 -0700

What possible rational is there for SWD to belong in the OAuth working group and in the security area?

EHL

> Of Mike Jones
> Sent: Thursday, October 20, 2011 12:12 PM
> To: Hannes Tschofenig; OAuth WG
> Responding to Eran's comments on SWD versus host-meta, these specs have
> significantly different goals and use substantially different mechanisms with
> different privacy characteristics.  Also, if you compare the relative complexity
> of the example at http://tools.ietf.org/html/draft-hammer-hostmeta-
> 17#appendix-A versus the example at http://tools.ietf.org/html/draft-jones-
> simple-web-discovery-01#section-1, you can see why SWD was chosen for
> use in OpenID Connect to discover OAuth authorization and resource server
> endpoints.
> 
> 				-- Mike
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Oct 2011 19:45:42 +0000

Because it's intended for (and used for) discovery of OAuth endpoints...

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 12:42 PM
To: Mike Jones; Hannes Tschofenig; OAuth WG
Subject: RE: [OAUTH-WG] Rechartering

EHL

> 3.  JSON Web Token (JWT) Bearer Token Profile 4.  Token Revocation
> 
> Responding to Eran's comments on SWD versus host-meta, these specs 
> have significantly different goals and use substantially different 
> mechanisms with different privacy characteristics.  Also, if you 
> compare the relative complexity of the example at 
> http://tools.ietf.org/html/draft-hammer-hostmeta-
> use in OpenID Connect to discover OAuth authorization and resource 
> server endpoints.
> 
> 				-- Mike
> 
> in preparation of the upcoming IETF meeting Barry and I would like to 
> start a re-chartering discussion.  We both are currently attending the 
> Internet Identity Workshop and so we had the chance to solicit input 
> from the participants. This should serve as a discussion starter.
> 
> a) Are you interested in any of the above-listed items? (as a 
> reviewer, co- author, implementer, or someone who would like to 
> deploy). It is also useful to know if you think that we shouldn't work on a specific item.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 20 Oct 2011 12:52:06 -0700

We also use HTTP, but we don't discuss it here.

OAuth discovery, automation, cross-vendor interop, and dynamic client registration are all part of one big topic. Before we can discuss any particular drafts or proposals, we must first understand the problem space, collect use cases and requirements, and figure out what we are trying to solve. Then we can decide if this is big enough for a new working group or not and charter the work. Once the WG starts working on it, it can decide based on the requirements which technologies to use and SWD can be one option.

However, even if an OAuth-related effort decides to use SWD, it is still not the place to work on it. SWD is clearly an Application area work and should be discussed there.

EHL

> From: Mike Jones [mailto:[email-masked]]
> Sent: Thursday, October 20, 2011 12:46 PM
> To: Eran Hammer-Lahav; Hannes Tschofenig; OAuth WG

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Oct 2011 13:25:20 -0700

There are various factors that play a role here, such as 
* where work first got proposed,
* where the expertise is, 
* where the main audience is, 
* etc. 

We will definitely talk to our AD but it is already a good start to hear whether there is interest in a specific item in general. If there is no interest then any other question goes away pretty quickly.  

Ciao
Hannes

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 20 Oct 2011 17:28:43 -0400

I agree.

To this end, are we going to have a rechartering discussion?  I would 
very much support that.  We have a number of things waiting, discovery 
being one of them.

Igor

On 10/20/2011 1:18 PM, Hannes Tschofenig wrote:
> the past that the JSON signature&  encryption work would go into JOES (earlier WOES) and the home for JWT is the OAuth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Oct 2011 00:56:37 +0200

Hi all,

my prioritization is driven by the goal to make OAuth the  
authorization framework of choice for any internet standard protocol,  
such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is  
missing from my point of view and explain some thoughts how to fill  
the gaps.

A standard protocol is defined in terms of resource types and messages  
by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many  
places, and used by different but deployment-independent clients.  
OAuth-based protocol specifications must also define scope values  
(e.g. read, write, send) and their relation to the resource types and  
messages. The different deployments expose the standard protocol on  
different resource server endpoints. In my opinion, it is fundamental  
to clearly distinguish scope values (standardized, static) and   
resource server addresses (deployment specific) and to manage their  
relationships. The current scope definition is much to weak and  
insufficient. Probably, the UMA concepts of hosts, resources sets, and  
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service provider  
before they are deployed. Would you really expect IMAP clients, e.g.  
Thunderbird, to register with any a-Mail services upfront? So clients  
should be given a way to register dynamically to the authorization  
servers. This should also allow us to cover "client instance" aspects.  
It is interesting to note, that such a mechanism would allow us to get  
rid of secret-less clients and the one-time usage requirement for  
authorization codes.

We also assume the client to know the URLs of the resource server and  
the corresponding authorization server and to use HTTPS server  
authentication to verify the resource server's authenticity. This is  
impossible in the standard scenario. Clients must be able to discover  
the authorization server a particular resource server relies on at  
runtime. The discovery mechanism could be specified by the OAuth WG,  
but could also be part of an application protocols specification. But  
we MUST find another way to prevent token phishing by counterfeit  
resource servers.

As one approach, the client could pass the (previously HTTPS  
validated) resource server's URL with the authorization request. The  
authorization server should then refuse such requests for any unknown  
(counterfeit) resource servers. Such an additional parameter could  
also serve as namespace for scope values and enable service providers  
to run multiple instances of the same service within a single  
deployment.

If the additional data enlarges the request payload to much, we could  
consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard  
protocols and we will see plenty of deployments with a bunch of  
different OAuth protected resource servers. Shall this servers all be  
accessible with a single token? In my opinion, this would cause  
security, privacy and/or scalability/performance problems. To give  
just the most obvious example, the target audience of such a token  
cannot be restricted enough, which may allow a resource server (or an  
attacker in control of it) to abuse the token on other servers. But  
the current design of the code grant type forces deployments to use  
the same token for all services. What is needed from my point of view  
is a way to request and issue multiple server-specific access tokens  
with a single authorization process.

I've been advocating this topic for a long time now and I'm still  
convinced this is required to really complete the core design. We at  
Deutsche Telekom needed and implemented this function on top of the  
existing core. In my opinion, a core enhancement would be easier to  
handle and more powerful. If others support this topic, I would be  
willed to submit an I-D describing a possible solution.

If we take standards really seriously, then service providers should  
be given the opportunity to implement their service by utilizing  
standard server implementations. This creates the challenge to find a  
standardized protocol between authorization server and resource server  
to exchange authorization data. Depending on the token design  
(self-contained vs. handle) this could be solved by either  
standardizing a token format (JWT) or an authorization API.

Based on the rationale given above, my list is as follows (topics w/o  
I-D are marked with *):

- Revocation (low hanging fruit since I-D is ready and implemented in  
some places)
- Resource server notion*
- Multiple access tokens*
- Dynamic client registration
  1) Dynamic Client Registration Protocol
  4) Client Instance Extension
- Discovery
  (10) Simple Web Discovery, probably other specs as well
- (6) JSON Web Token
- (7) JSON Web Token (JWT) Bearer Profile
- 8) User Experience Extension
- Device flow
- 9) Request by Reference
  (depending resource server notion and multiple access tokens)

regards,
Torsten.
Zitat von Hannes Tschofenig <[email-masked]>:

> Hi all,
>
> in preparation of the upcoming IETF meeting Barry and I would like  
> to start a re-chartering discussion.  We both are currently  
> attending the Internet Identity Workshop and so we had the chance to  
> solicit input from the participants. This should serve as a  
> discussion starter.
>
> reviewer, co-author, implementer, or someone who would like to

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 22 Oct 2011 07:00:53 -0700

Hi.

Just a clarification:

Although my expired draft is 'request by reference', what was proposed
through it at the iiw really is a generalized JSON based claim request
capability. It could be passed by value as JSON or could be passed by
reference. The later is an optimization for bandwidth constrained network as
well as strengthening security in some ways. This capability already exists
in OpenID Connect but it is actually an underpinning transport, so it
probably should belong to OAuth instead. This was the primary reason for the
proposal.

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi all,
>
> my prioritization is driven by the goal to make OAuth the authorization
> framework of choice for any internet standard protocol, such as WebDAV,
> IMAP, SMTP or SIP. So let me first explain what is missing from my point of
> view and explain some thoughts how to fill the gaps.
>
> A standard protocol is defined in terms of resource types and messages by a
> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and
> used by different but deployment-independent clients. OAuth-based protocol
> specifications must also define scope values (e.g. read, write, send) and
> their relation to the resource types and messages. The different deployments
> expose the standard protocol on different resource server endpoints. In my
> opinion, it is fundamental to clearly distinguish scope values
> (standardized, static) and  resource server addresses (deployment specific)
> and to manage their relationships. The current scope definition is much to
> weak and insufficient. Probably, the UMA concepts of hosts, resources sets,
> and corresponding scopes could be adopted for that purpose.
>
> OAuth today requires clients to register with the service provider before
> they are deployed. Would you really expect IMAP clients, e.g. Thunderbird,
> to register with any a-Mail services upfront? So clients should be given a
> way to register dynamically to the authorization servers. This should also
> allow us to cover "client instance" aspects. It is interesting to note, that
> such a mechanism would allow us to get rid of secret-less clients and the
> one-time usage requirement for authorization codes.
>
> We also assume the client to know the URLs of the resource server and the
> corresponding authorization server and to use HTTPS server authentication to
> verify the resource server's authenticity. This is impossible in the
> standard scenario. Clients must be able to discover the authorization server
> a particular resource server relies on at runtime. The discovery mechanism
> could be specified by the OAuth WG, but could also be part of an application
> protocols specification. But we MUST find another way to prevent token
> phishing by counterfeit resource servers.
>
> As one approach, the client could pass the (previously HTTPS validated)
> resource server's URL with the authorization request. The authorization
> server should then refuse such requests for any unknown (counterfeit)
> resource servers. Such an additional parameter could also serve as namespace
> for scope values and enable service providers to run multiple instances of
> the same service within a single deployment.
>
> Let's now assume, OAuth is successful in the world of standard protocols
> and we will see plenty of deployments with a bunch of different OAuth
> protected resource servers. Shall this servers all be accessible with a
> single token? In my opinion, this would cause security, privacy and/or
> scalability/performance problems. To give just the most obvious example, the
> target audience of such a token cannot be restricted enough, which may allow
> a resource server (or an attacker in control of it) to abuse the token on
> other servers. But the current design of the code grant type forces
> deployments to use the same token for all services. What is needed from my
> point of view is a way to request and issue multiple server-specific access
> tokens with a single authorization process.
>
> I've been advocating this topic for a long time now and I'm still convinced
> this is required to really complete the core design. We at Deutsche Telekom
> needed and implemented this function on top of the existing core. In my
> opinion, a core enhancement would be easier to handle and more powerful. If
> others support this topic, I would be willed to submit an I-D describing a
> possible solution.
>
> If we take standards really seriously, then service providers should be
> given the opportunity to implement their service by utilizing standard
> server implementations. This creates the challenge to find a standardized
> protocol between authorization server and resource server to exchange
> authorization data. Depending on the token design (self-contained vs.
> handle) this could be solved by either standardizing a token format (JWT) or
> an authorization API.
>
> Based on the rationale given above, my list is as follows (topics w/o I-D
> are marked with *):
>
> - Revocation (low hanging fruit since I-D is ready and implemented in some
> places)
>> Internet Identity Workshop and so we had the chance to solicit input from
>> the participants. This should serve as a discussion starter.
>>
>> http://datatracker.ietf.org/**doc/draft-hardjono-oauth-**dynreg/<http://datatracker.ietf.org/doc/draft-hardjono-oauth-dynreg/>
>>
>> 2) Token Revocation
>>
>> Available document:
>> http://datatracker.ietf.org/**doc/draft-lodderstedt-oauth-**revocation/<http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/>
>>
>> 3) UMA
>>
>> Available document:
>> http://datatracker.ietf.org/**doc/draft-hardjono-oauth-**umacore/<http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/>
>>
>> http://tools.ietf.org/id/**draft-richer-oauth-instance-**00.txt<http://tools.ietf.org/id/draft-richer-oauth-instance-00.txt>
>>
>> 5) XML Encoding
>>
>> Available document:
>> http://tools.ietf.org/id/**draft-richer-oauth-xml-00.txt<http://tools.ietf.org/id/draft-richer-oauth-xml-00.txt>
>>
>> 6) JSON Web Token
>>
>> Available document:
>> http://tools.ietf.org/html/**draft-jones-json-web-token-05<http://tools.ietf.org/html/draft-jones-json-web-token-05>
>>
>> http://tools.ietf.org/html/**draft-jones-oauth-jwt-bearer-**00<http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-00>
>>
>> http://tools.ietf.org/html/**draft-recordon-oauth-v2-ux-00<http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00>
>>
>> 9) Request by Reference
>>
>> Available document:
>> http://tools.ietf.org/html/**draft-sakimura-oauth-requrl-00<http://tools.ietf.org/html/draft-sakimura-oauth-requrl-00>
>>
>> 10) Simple Web Discovery
>>
>> Available document:
>> http://tools.ietf.org/html/**draft-jones-simple-web-**discovery-00<http://tools.ietf.org/html/draft-jones-simple-web-discovery-00>
>>
>> ----------------
>>
>> a) Are you interested in any of the above-listed items? (as a reviewer,
>> co-author, implementer, or someone who would like to deploy). It is also
>> useful to know if you think that we shouldn't work on a specific item.
>>
>> ______________________________**_________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>
>
>
>
> ______________________________**_________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Eve Maler <[email-masked]>
Date: Sat, 22 Oct 2011 22:13:32 -0700

Hi Torsten et al.,

Prioritizing new work items based on an overarching goal seems like a good idea. If Torsten's goal of making OAuth "the authorization framework of choice for any internet protocol" is more widely shared, it gives a useful basis for assessing the proposals consistently. I think this is a great goal, myself. OAuth 2.0 has gone pretty far in this direction, but not all the way.

Although UMA can be seen as a relatively large and comprehensive "application of OAuth" in the spec's current form, Torsten's suggestion to look at it in pieces is certainly consistent with the intent of the UMA group, and we're happy to break our future contributions down into modules where it makes sense.

Here are some obvious bits of UMA functionality that could be considered:

- (As Torsten notes:) Machine-readable descriptions of scopes (whether proprietary or standardized) and interoperable ways to attach them to labeled resource sets. This is where UMA's ability to differentially protect arbitrary Web resources, such as each photo in an album, comes from.

- Standard interface between authorization server and resource server.

- Clean distinction between authenticating a client and authorizing the operator of the client for access. Achieving this could further the goal of OAuth as an authorization framework of choice. Note that this is where UMA's abilities to allow delegated authorization to third parties, and to do true claims-based authorization, come from. 

The work that we'd done in the UMA group and contributed to IETF on dynamic client registration seems to have influenced other work in this area, which is great. UMA, among others, definitely needs the ability to register "client instances", but we currently point off to the OpenID Connect spec for this. We'd love to be able to point to a registration spec that has sedimented into the OAuth core (or satellite specs), since it seems widely desired at this level.

	Eve

On 20 Oct 2011, at 3:56 PM, Torsten Lodderstedt wrote:

> Hi all,
> 
> my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps.
> 
> A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and  resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose.
> 
> OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover "client instance" aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes.
> 
> We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers.
> 
> As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment.
> 
> If the additional data enlarges the request payload to much, we could consider to adopt the "request by reference" proposal.
> 
> Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process.
> 
> I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution.
> 
> If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API.
> 
> Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *):
> 
> - Revocation (low hanging fruit since I-D is ready and implemented in some places)

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Dan Taflin <[email-masked]>
Date: Tue, 25 Oct 2011 22:36:35 +0000

I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operations into two main categories: protected and confidential. (A possible third category, public, would not require any authorization at all). Protected operations would be user-specific operations that don't involve the passing of any sensitive information, such as image search results tagged with information about whether each image is available for download by that user. Confidential operations would involve passing user data, like user registration or e-commerce. We would like to protect each category of operations with distinct tokens: a general-use token for protected operations, and a secure token for confidential operations.

We could use the scope parameter to specify either "protected" or "confidential". Currently the oauth spec allows a Refresh token to request a new token with reduced scope from the one originally issued, but there is no way to obtain a new token with a completely different scope without doing the full oauth dance a second time.

Dan

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Hi all,

regards,
Torsten.

---

From: Dave Rochwerger <[email-masked]>
Date: Tue, 25 Oct 2011 16:08:20 -0700

Is separating this out into 2 different tokens, really the best way to solve
your use case?

It sounds to me that you simply want to track/log the two types of accesses
differently, which can be done entirely outside of the oauth2 process.
Just bucket your operations into two piles internally and track
appropriately (which you would have to do anyway with scopes).

Scopes are the specific access that the end user grants to a 3rd party to
access their protected resources.

When an application, to use your example, asks for the scope "protected
confidential", they are providing those two levels of access to the 3rd
party application. If the user says "allow", then that application has all
the access that those two scopes provides.

Rather than getting applications to then further choose between two tokens
to simply delineate two sets of operations seems like the wrong place to be
doing this.
i.e., why does the 3rd party application have to choose which token to use
for each set of operations? - the user has already granted both. The
resource server can do whatever tracking/logging it wants based on the
actual operations requested - using the single token in this case.

Regards,
Dave

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <[email-masked]>wrote:

> I would like to second Torsten's pitch for the ability to return multiple
> access tokens with a single authorization process. The use case for my
> company is to segment operations into two main categories: protected and
> confidential. (A possible third category, public, would not require any
> authorization at all). Protected operations would be user-specific
> operations that don't involve the passing of any sensitive information, such
> as image search results tagged with information about whether each image is
> available for download by that user. Confidential operations would involve
> passing user data, like user registration or e-commerce. We would like to
> protect each category of operations with distinct tokens: a general-use
> token for protected operations, and a secure token for confidential
> operations.
>
> We could use the scope parameter to specify either "protected" or
> "confidential". Currently the oauth spec allows a Refresh token to request a
> new token with reduced scope from the one originally issued, but there is no
> way to obtain a new token with a completely different scope without doing
> the full oauth dance a second time.
>
> Dan
>

---

From: Dan Taflin <[email-masked]>
Date: Tue, 25 Oct 2011 23:21:01 +0000

You're right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we'd like to allow "protected" operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token).

In contrast, "confidential" operations would only be callable over https. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work.

Oauth today basically requires https for all bearer token implementations. I would like to see this relaxed somewhat.

Dan

From: Dave Rochwerger [mailto:[email-masked]]
Sent: Tuesday, October 25, 2011 4:08 PM
To: Dan Taflin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

Is separating this out into 2 different tokens, really the best way to solve your use case?

It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process.
Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes).

Scopes are the specific access that the end user grants to a 3rd party to access their protected resources.

When an application, to use your example, asks for the scope "protected confidential", they are providing those two levels of access to the 3rd party application. If the user says "allow", then that application has all the access that those two scopes provides.

Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the wrong place to be doing this.
i.e., why does the 3rd party application have to choose which token to use for each set of operations? - the user has already granted both. The resource server can do whatever tracking/logging it wants based on the actual operations requested - using the single token in this case.

Regards,
Dave

On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <[email-masked]<mailto:[email-masked]>> wrote:
I would like to second Torsten's pitch for the ability to return multiple access tokens with a single authorization process. The use case for my company is to segment operations into two main categories: protected and confidential. (A possible third category, public, would not require any authorization at all). Protected operations would be user-specific operations that don't involve the passing of any sensitive information, such as image search results tagged with information about whether each image is available for download by that user. Confidential operations would involve passing user data, like user registration or e-commerce. We would like to protect each category of operations with distinct tokens: a general-use token for protected operations, and a secure token for confidential operations.

Dan

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 20, 2011 3:57 PM
To: Hannes Tschofenig
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering
Hi all,

regards,
Torsten.
Zitat von Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dave Rochwerger <[email-masked]>
Date: Tue, 25 Oct 2011 16:33:03 -0700

Hi Dan,

I think we are going down the wrong path here.
Basically, you've started with the premise of wanting plain HTTP scheme (in
some circumstances), which has caused you to suggest both of, firstly,
relaxing the only method of encryption in oauth2 and secondly, to further
complicate the protocol by allowing multiple tokens to be returned.

OAuth2 (unlike version 1) has no signatures or other encryption - it relies
solely on SSL. Therefore any relaxation of this requirement breaks security
wide open (even in your specific short-term token case).

I think you're asking the wrong question.

We should not ask "to relax the SSL requirement", but rather - Why do you
not want to use SSL?

With today's computer speeds, there is no reason not to use SSL. The plain
HTTP scheme does not really provide a noticeable enough performance
boost. On a side note, if the likes of Google's SPDY is anything to go by,
the future might always be SSL only anyway.

Cheers,
Dave

On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin <[email-masked]>wrote:

>  You’re right, if tracking was all we needed then a single token would
> suffice. The reason for two tokens has more to do with the fact that we’d
> like to allow “protected” operations to be called over plain http. This
> opens up the possibility of an attacker intercepting the token for his own
> nefarious use. If the only thing that token gave him access to was
> relatively benign operations like image search, it would be an acceptable
> risk (especially if we have a relatively short lifespan for the token).***
> *
>
> ** **
>
> In contrast, “confidential” operations would only be callable over https.
> By requiring a different token for them (and not allowing that token to be
> used for unprotected operations) we prevent it from being intercepted. This
> design intentionally mimics the way secure and non-secure http cookies work.
> ****
>
> ** **
>
> Oauth today basically requires https for all bearer token implementations.
> I would like to see this relaxed somewhat.****
>
> ** **
>
> Dan****
>
> ** **
>
> *From:* Dave Rochwerger [mailto:[email-masked]]
> *Sent:* Tuesday, October 25, 2011 4:08 PM
> *To:* Dan Taflin
>
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Rechartering****
>
>  ** **
>
> Is separating this out into 2 different tokens, really the best way to
> solve your use case?****
>
> ** **
>
> differently, which can be done entirely outside of the oauth2 process.****
>
> appropriately (which you would have to do anyway with scopes).****
>
> ** **
>
> access their protected resources.****
>
> ** **
>
> the access that those two scopes provides.****
>
> ** **
>
> doing this.****
> actual operations requested - using the single token in this case.****
>
> ** **
>
> Regards,****
>
> Dave****
>
> ** **
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin <[email-masked]>
> wrote:****
>
> Dan****
> Subject: Re: [OAUTH-WG] Rechartering****
>
> Hi all,
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 26 Oct 2011 09:15:50 -0700

Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want.

EHL

> Of Dan Taflin
> Sent: Tuesday, October 25, 2011 3:37 PM
> To: OAuth WG
> I would like to second Torsten's pitch for the ability to return multiple access
> tokens with a single authorization process. The use case for my company is to
> segment operations into two main categories: protected and confidential. (A
> possible third category, public, would not require any authorization at all).
> Protected operations would be user-specific operations that don't involve
> the passing of any sensitive information, such as image search results tagged
> with information about whether each image is available for download by that
> user. Confidential operations would involve passing user data, like user
> registration or e-commerce. We would like to protect each category of
> operations with distinct tokens: a general-use token for protected
> operations, and a secure token for confidential operations.
> 
> used by different but deployment-independent clients.
> OAuth-based protocol specifications must also define scope values (e.g.
> read, write, send) and their relation to the resource types and messages. The
> different deployments expose the standard protocol on different resource
> server endpoints. In my opinion, it is fundamental
> relationships. The current scope definition is much to weak and insufficient.
> Probably, the UMA concepts of hosts, resources sets, and corresponding
> scopes could be adopted for that purpose.
> 
> they are deployed. Would you really expect IMAP clients, e.g.
> Thunderbird, to register with any a-Mail services upfront? So clients should
> be given a way to register dynamically to the authorization servers. This
> should also allow us to cover "client instance" aspects.
> It is interesting to note, that such a mechanism would allow us to get rid of
> secret-less clients and the one-time usage requirement for authorization
> codes.
> 
> corresponding authorization server and to use HTTPS server authentication
> to verify the resource server's authenticity. This is impossible in the standard
> scenario. Clients must be able to discover the authorization server a
> particular resource server relies on at runtime. The discovery mechanism
> (counterfeit) resource servers. Such an additional parameter could also serve
> as namespace for scope values and enable service providers to run multiple
> instances of the same service within a single deployment.
> 
> Let's now assume, OAuth is successful in the world of standard protocols and
> we will see plenty of deployments with a bunch of different OAuth
> protected resource servers. Shall this servers all be accessible with a single
> token? In my opinion, this would cause security, privacy and/or
> scalability/performance problems. To give just the most obvious example,
> the target audience of such a token cannot be restricted enough, which may
> allow a resource server (or an attacker in control of it) to abuse the token on
> I've been advocating this topic for a long time now and I'm still convinced this
> is required to really complete the core design. We at Deutsche Telekom
> opinion, a core enhancement would be easier to handle and more powerful.
> If others support this topic, I would be willed to submit an I-D describing a
> possible solution.
> 
> If we take standards really seriously, then service providers should be given
> the opportunity to implement their service by utilizing standard server
> implementations. This creates the challenge to find a standardized protocol
> between authorization server and resource server to exchange authorization
> data. Depending on the token design (self-contained vs. handle) this could
> be solved by either standardizing a token format (JWT) or an authorization
> API.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 26 Oct 2011 20:16:55 +0200

Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based 
request format would allow for more complex requests (e.g. carrying 
resource server URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used 
in the current OpenID connect spec requires OpenID connect clients and 
servers to handle OAuth request parameters differently than for standard 
OAuth requests. Introducing the JSON based claim request capability to 
OAuth would be a way to cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
> reference. The later is an optimization for bandwidth constrained 
> network as well as strengthening security in some ways. This 
> capability already exists in OpenID Connect but it is actually an 
> underpinning transport, so it probably should belong to OAuth instead. 
> This was the primary reason for the proposal.
>
> Nat
>
> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     authorization framework of choice for any internet standard
>     protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first
>     explain what is missing from my point of view and explain some
>     thoughts how to fill the gaps.
>
>     A standard protocol is defined in terms of resource types and
>     messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented
>     in many places, and used by different but deployment-independent
>     clients. OAuth-based protocol specifications must also define
>     scope values (e.g. read, write, send) and their relation to the
>     resource types and messages. The different deployments expose the
>     standard protocol on different resource server endpoints. In my
>     (standardized, static) and  resource server addresses (deployment
>     specific) and to manage their relationships. The current scope
>     definition is much to weak and insufficient. Probably, the UMA
>     concepts of hosts, resources sets, and corresponding scopes could
>     be adopted for that purpose.
>
>     before they are deployed. Would you really expect IMAP clients,
>     e.g. Thunderbird, to register with any a-Mail services upfront? So
>     clients should be given a way to register dynamically to the
>     authorization servers. This should also allow us to cover "client
>     instance" aspects. It is interesting to note, that such a
>     mechanism would allow us to get rid of secret-less clients and the
>     We also assume the client to know the URLs of the resource server
>     and the corresponding authorization server and to use HTTPS server
>     authentication to verify the resource server's authenticity. This
>     is impossible in the standard scenario. Clients must be able to
>     discover the authorization server a particular resource server
>     relies on at runtime. The discovery mechanism could be specified
>     by the OAuth WG, but could also be part of an application
>     protocols specification. But we MUST find another way to prevent
>     token phishing by counterfeit resource servers.
>
>     validated) resource server's URL with the authorization request.
>     The authorization server should then refuse such requests for any
>     unknown (counterfeit) resource servers. Such an additional
>     parameter could also serve as namespace for scope values and
>     enable service providers to run multiple instances of the same
>     service within a single deployment.
>
>     If the additional data enlarges the request payload to much, we
>     could consider to adopt the "request by reference" proposal.
>
>     different OAuth protected resource servers. Shall this servers all
>     be accessible with a single token? In my opinion, this would cause
>     cannot be restricted enough, which may allow a resource server (or
>     an attacker in control of it) to abuse the token on other servers.
>     But the current design of the code grant type forces deployments
>     to use the same token for all services. What is needed from my
>     point of view is a way to request and issue multiple
>     server-specific access tokens with a single authorization process.
>
>     convinced this is required to really complete the core design. We
>     at Deutsche Telekom needed and implemented this function on top of
>     the existing core. In my opinion, a core enhancement would be
>     easier to handle and more powerful. If others support this topic,
>     I would be willed to submit an I-D describing a possible solution.
>
>     If we take standards really seriously, then service providers
>     should be given the opportunity to implement their service by
>     utilizing standard server implementations. This creates the
>     challenge to find a standardized protocol between authorization
>     server and resource server to exchange authorization data.
>     Depending on the token design (self-contained vs. handle) this
>     could be solved by either standardizing a token format (JWT) or an
>     authorization API.
>
>         in preparation of the upcoming IETF meeting Barry and I would
>         like to start a re-chartering discussion.  We both are
>         currently attending the Internet Identity Workshop and so we
>         had the chance to solicit input from the participants. This
>         should serve as a discussion starter.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 26 Oct 2011 17:34:03 -0400

Actually, I think we need to document the use case.

Igor

On 10/25/2011 7:08 PM, Dave Rochwerger wrote:
> solve your use case?
> It sounds to me that you simply want to track/log the two types of 
> accesses differently, which can be done entirely outside of the oauth2 
> process.
> When an application, to use your example, asks for the scope 
> "protected confidential", they are providing those two levels of 
> access to the 3rd party application. If the user says "allow", then 
> that application has all the access that those two scopes provides.
>
> Rather than getting applications to then further choose between two 
> tokens to simply delineate two sets of operations seems like the wrong 
> place to be doing this.
> i.e., why does the 3rd party application have to choose which token to 
> use for each set of operations? - the user has already granted both. 
> The resource server can do whatever tracking/logging it wants based on 
> the actual operations requested - using the single token in this case.
>
> Regards,
> Dave
>
> On Tue, Oct 25, 2011 at 3:36 PM, Dan Taflin 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I would like to second Torsten's pitch for the ability to return
>     multiple access tokens with a single authorization process. The
>     use case for my company is to segment operations into two main
>     categories: protected and confidential. (A possible third
>     category, public, would not require any authorization at all).
>     Protected operations would be user-specific operations that don't
>     involve the passing of any sensitive information, such as image
>     search results tagged with information about whether each image is
>     available for download by that user. Confidential operations would
>     involve passing user data, like user registration or e-commerce.
>     We would like to protect each category of operations with distinct
>     tokens: a general-use token for protected operations, and a secure
>     token for confidential operations.
>
>     "confidential". Currently the oauth spec allows a Refresh token to
>     request a new token with reduced scope from the one originally
>     issued, but there is no way to obtain a new token with a
>     completely different scope without doing the full oauth dance a
>     second time.
>
>     Dan
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 27 Oct 2011 07:30:08 +0900

HI Torsten,

I and John just refreshed the I-D to be more in-line with what we do with
OpenID Connect.

http://tools.ietf.org/html/draft-sakimura-oauth-requrl-01

As you point out, this would solve the duplication / non-standard behavior
that OpenID Connect requires.

Cheers,

Nat

On Thu, Oct 27, 2011 at 3:16 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> request format would allow for more complex requests (e.g. carrying resource
> server URLs and corresponding scope values ;-)).
>
> Please note: I also think the way this mechanism is introduced and used in
> the current OpenID connect spec requires OpenID connect clients and servers
> to handle OAuth request parameters differently than for standard OAuth
> requests. Introducing the JSON based claim request capability to OAuth would
> be a way to cope with this.
>
> regards,
> Torsten.
>
>> A standard protocol is defined in terms of resource types and messages by
>> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and
>> Deutsche Telekom needed and implemented this function on top of the existing
>> core. In my opinion, a core enhancement would be easier to handle and more
>> powerful. If others support this topic, I would be willed to submit an I-D
>> describing a possible solution.
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 26 Oct 2011 19:31:43 -0300

Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:

> Hi Nat,
> 
> I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). 
> 
> Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this.
> 
> regards,
> Torsten.
> 
>> Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. 
>> 
>> Nat
>> 
>> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <[email-masked]> wrote:
>> Hi all,
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 26 Oct 2011 19:42:32 -0300

The Connect use case was a bit different for needing a id_token however your proposal would work if being less efficient for the code flow.

However in the implicit flow you can't get a refresh token so the only option is to make the user go through multiple authorizations, or return multiple tokens.

We went with the multiple token option, by registering new response_type.

Not necessarily the perfect solution but one that works as an extension.

John B.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 27 Oct 2011 07:22:33 +0200

why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
> It is essentially  a standardization of the method we are using in 
> openID Connect to make signed requests to the Authorization server.
>
> We do have the issue that parameters in the signed/encrypted request 
> necessarily duplicate the query parameters to keep it a valid OAuth 
> request plus an extension.
>
> Even if it doesn't wind up as a OAuth WG item it is probably worth 
> people looking at it before the final openID spec is voted on.
>
> Regards
> John B.
>
>> I think your proposal would be a useful OAuth enhancement. A 
>> JSON-based request format would allow for more complex requests (e.g. 
>> carrying resource server URLs and corresponding scope values ;-)).
>>
>> Please note: I also think the way this mechanism is introduced and 
>> used in the current OpenID connect spec requires OpenID connect 
>> clients and servers to handle OAuth request parameters differently 
>> than for standard OAuth requests. Introducing the JSON based claim 
>> request capability to OAuth would be a way to cope with this.
>>
>> regards,
>> Torsten.
>>
>>> Although my expired draft is 'request by reference', what was 
>>> proposed through it at the iiw really is a generalized JSON based 
>>> claim request capability. It could be passed by value as JSON or 
>>> could be passed by reference. The later is an optimization for 
>>> bandwidth constrained network as well as strengthening security in 
>>> some ways. This capability already exists in OpenID Connect but it 
>>> is actually an underpinning transport, so it probably should belong 
>>> to OAuth instead. This was the primary reason for the proposal.
>>>
>>> Nat
>>>
>>>     messages by a body (e.g. IETF, OIDF, OMA), (hopefully)
>>>     implemented in many places, and used by different but
>>>     deployment-independent clients. OAuth-based protocol
>>>     specifications must also define scope values (e.g. read, write,
>>>     send) and their relation to the resource types and messages. The
>>>     different deployments expose the standard protocol on different
>>>     resource server endpoints. In my opinion, it is fundamental to
>>>     clearly distinguish scope values (standardized, static) and
>>>      resource server addresses (deployment specific) and to manage
>>>     their relationships. The current scope definition is much to
>>>     weak and insufficient. Probably, the UMA concepts of hosts,
>>>     resources sets, and corresponding scopes could be adopted for
>>>     that purpose.
>>>
>>>     OAuth today requires clients to register with the service
>>>     provider before they are deployed. Would you really expect IMAP
>>>     clients, e.g. Thunderbird, to register with any a-Mail services
>>>     upfront? So clients should be given a way to register
>>>     dynamically to the authorization servers. This should also allow
>>>     us to cover "client instance" aspects. It is interesting to
>>>     note, that such a mechanism would allow us to get rid of
>>>     secret-less clients and the one-time usage requirement for
>>>     authorization codes.
>>>
>>>     We also assume the client to know the URLs of the resource
>>>     server and the corresponding authorization server and to use
>>>     HTTPS server authentication to verify the resource server's
>>>     authenticity. This is impossible in the standard scenario.
>>>     Clients must be able to discover the authorization server a
>>>     particular resource server relies on at runtime. The discovery
>>>     mechanism could be specified by the OAuth WG, but could also be
>>>     part of an application protocols specification. But we MUST find
>>>     another way to prevent token phishing by counterfeit resource
>>>     servers.
>>>
>>>     The authorization server should then refuse such requests for
>>>     any unknown (counterfeit) resource servers. Such an additional
>>>     different OAuth protected resource servers. Shall this servers
>>>     all be accessible with a single token? In my opinion, this would
>>>     cause security, privacy and/or scalability/performance problems.
>>>     To give just the most obvious example, the target audience of
>>>     such a token cannot be restricted enough, which may allow a
>>>     resource server (or an attacker in control of it) to abuse the
>>>     token on other servers. But the current design of the code grant
>>>     type forces deployments to use the same token for all services.
>>>     What is needed from my point of view is a way to request and
>>>     issue multiple server-specific access tokens with a single
>>>     authorization process.
>>>
>>>     I've been advocating this topic for a long time now and I'm
>>>     still convinced this is required to really complete the core
>>>     design. We at Deutsche Telekom needed and implemented this
>>>     function on top of the existing core. In my opinion, a core
>>>     enhancement would be easier to handle and more powerful. If
>>>     others support this topic, I would be willed to submit an I-D
>>>     could be solved by either standardizing a token format (JWT) or
>>>     an authorization API.
>>>
>>>         in preparation of the upcoming IETF meeting Barry and I
>>>         would like to start a re-chartering discussion.  We both are
>>>         a) Are you interested in any of the above-listed items? (as
>>>         a reviewer, co-author, implementer, or someone who would
>>>         like to deploy). It is also useful to know if you think that
>>>         we shouldn't work on a specific item.
>>>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 27 Oct 2011 12:21:58 -0400

On 10/26/2011 6:31 PM, John Bradley wrote:

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 27 Oct 2011 12:25:08 -0400

Many thanks for pointing this!  It is *absolutely* (not "probably") 
worth studying.

Igor

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Oct 2011 13:52:31 -0300

Hopefully to make it more compatible with existing OAuth 2 libraries.    At least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and libraries.

John B.

---

From: [email-masked]
Date: Thu, 27 Oct 2011 17:33:13 +0000

Hi John,

why do you need to include the OAuth request parameters into the JSON document? I would expect OpenId Connect to extend OAuth none-intrusively. This would mean to use the JSON document for OpenId connect specific parameters only. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters could be omitted.

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-----Original Message-----
From: John Bradley <[email-masked]>
Date: Thu, 27 Oct 2011 13:52:31 
To: Torsten Lodderstedt<[email-masked]>
Cc: Nat Sakimura<[email-masked]>; OAuth WG<[email-masked]>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Oct 2011 10:49:23 -0700

John,

What is the reason behind having a separate ID_Token from the access Token?  I understand the tokens are used to retrieve different information, but not sure I fully understand why separate tokens are needed.

I ask because I recall others have asked for multi-token response….trying to understand if there is a general use case behind this requirement.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-10-27, at 10:33 AM, [email-masked] wrote:

> Date: Thu, 27 Oct 2011 13:52:31 -0300

---

From: Mike Jones <[email-masked]>
Date: Thu, 27 Oct 2011 17:55:41 +0000

In OpenID Connect, the two tokens are used to access two different sets of resources:  the "id_token" for claims about the logged-in session and the "code" token to access the UserInfo endpoint for claims about the user.

FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html for a write-up on encoding multiple response types.  (I'm told that at least parts of this are already being used by Google and Facebook.)

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, October 27, 2011 10:49 AM
To: [email-masked]
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

John,

I ask because I recall others have asked for multi-token response....trying to understand if there is a general use case behind this requirement.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2011-10-27, at 10:33 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi John,

regards,
Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland

________________________________
From: John Bradley <[email-masked]<mailto:[email-masked]>>
Date: Thu, 27 Oct 2011 13:52:31 -0300
To: Torsten Lodderstedt<[email-masked]<mailto:[email-masked]>>
Cc: Nat Sakimura<[email-masked]<mailto:[email-masked]>>; OAuth WG<[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

John B.

Regards
John B.

Hi Nat,

regards,
Torsten.

Just a clarification:

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

regards,
Torsten.

Hi all,

----------------

Available document:

2) Token Revocation

Available document:

3) UMA

Available document:

Available document:

5) XML Encoding

Available document:

6) JSON Web Token

Available document:

Available document:

Available document:

9) Request by Reference

Available document:

10) Simple Web Discovery

Available document:

----------------

Ciao
Hannes & Barry

---

From: Phil Hunt <[email-masked]>
Date: Thu, 27 Oct 2011 11:42:01 -0700

Mike,

Why can't the same access token be used for both services?  Is it because the services have different security systems and demand different tokens?  Why not a single token for both?

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-10-27, at 10:55 AM, Mike Jones wrote:

> In OpenID Connect, the two tokens are used to access two different sets of resources:  the “id_token” for claims about the logged-in session and the “code” token to access the UserInfo endpoint for claims about the user.
>  
> FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html for a write-up on encoding multiple response types.  (I’m told that at least parts of this are already being used by Google and Facebook.)
>  
>                                                                 -- Mike
>

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Oct 2011 15:58:14 -0300

Changing the subject to reflect the question.

Good question.

We did try to come up with a way to only have one token.

One of the requirements from the social network RP's was to get a identity token in the from channel that they could directly parse to customize the user experience.

Getting a code then exchanging it for a access token then getting the user_id was not acceptable.

Thus we needed to have a signed id_token, that however ran into conflict with providers current user-info endpoints and other OAuth protected resources.

The decision was made to keep the access tokens opaque to allow scopes for multiple resources to be attached to the access token.

Given that the id_token is signed JSON it is not a good thing to start passing it around with the user ID in it for privacy reasons.

I think that everyone agrees that sometimes you need differently scoped tokens from the same authorization.  

Using code and refresh tokens you can do that,  However not all flows support refresh tokens and down scoping.

John B.

---

From: George Fletcher <[email-masked]>
Date: Thu, 27 Oct 2011 16:24:36 -0400

The main reason to include the OAuth parameters in the request is to 
ensure that the request object was not modified in transit since the 
JSON request object can be signed. Agreed that it would be simpler if 
OAuth adopted the JSON request style.

Thanks,
George

On 10/27/11 1:33 PM, [email-masked] wrote:
> Hi John,
>
> why do you need to include the OAuth request parameters into the JSON 
> document? I would expect OpenId Connect to extend OAuth 
> none-intrusively. This would mean to use the JSON document for OpenId 
> connect specific parameters only. Alternatively, the JSON request 
> style could be adopted as part of OAuth. Then, the URI request 
> parameters could be omitted.
>
> regards,
> Torsten.
>
> ------------------------------------------------------------------------
> *From: * John Bradley <[email-masked]>
> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
> *To: *Torsten Lodderstedt<[email-masked]>
> *Cc: *Nat Sakimura<[email-masked]>; OAuth WG<[email-masked]>
> *Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
>
> Hopefully to make it more compatible with existing OAuth 2 libraries. 
>    At least leave open the possibility of dealing with it at a higher 
> level.
>
> The argument has been made that you probably need to modify the 
> library anyway to check that the duplicate parameters are a match.
>
> If there is consensus that the parameters should only be in the JSON 
> then we would happily not duplicate them.
>
>>>> JSON-based request format would allow for more complex requests 
>>>> (e.g. carrying resource server URLs and corresponding scope values 
>>>> ;-)).
>>>>
>>>>> is actually an underpinning transport, so it probably should 
>>>>> belong to OAuth instead. This was the primary reason for the 
>>>>> proposal.
>>>>>
>>>>> Nat
>>>>>
>>>>>     specifications must also define scope values (e.g. read,
>>>>>     write, send) and their relation to the resource types and
>>>>>     messages. The different deployments expose the standard
>>>>>     protocol on different resource server endpoints. In my
>>>>>     (standardized, static) and  resource server addresses
>>>>>     (deployment specific) and to manage their relationships. The
>>>>>     current scope definition is much to weak and insufficient.
>>>>>     Probably, the UMA concepts of hosts, resources sets, and
>>>>>     provider before they are deployed. Would you really expect
>>>>>     IMAP clients, e.g. Thunderbird, to register with any a-Mail
>>>>>     services upfront? So clients should be given a way to register
>>>>>     dynamically to the authorization servers. This should also
>>>>>     allow us to cover "client instance" aspects. It is interesting
>>>>>     to note, that such a mechanism would allow us to get rid of
>>>>>     mechanism could be specified by the OAuth WG, but could also
>>>>>     be part of an application protocols specification. But we MUST
>>>>>     find another way to prevent token phishing by counterfeit
>>>>>     resource servers.
>>>>>
>>>>>     validated) resource server's URL with the authorization
>>>>>     request. The authorization server should then refuse such
>>>>>     requests for any unknown (counterfeit) resource servers. Such
>>>>>     an additional parameter could also serve as namespace for
>>>>>     scope values and enable service providers to run multiple
>>>>>     If the additional data enlarges the request payload to much,
>>>>>     we could consider to adopt the "request by reference" proposal.
>>>>>
>>>>>     protocols and we will see plenty of deployments with a bunch
>>>>>     of different OAuth protected resource servers. Shall this
>>>>>     servers all be accessible with a single token? In my opinion,
>>>>>     this would cause security, privacy and/or
>>>>>     scalability/performance problems. To give just the most
>>>>>     obvious example, the target audience of such a token cannot be
>>>>>     restricted enough, which may allow a resource server (or an
>>>>>     attacker in control of it) to abuse the token on other
>>>>>     servers. But the current design of the code grant type forces
>>>>>     deployments to use the same token for all services. What is
>>>>>     needed from my point of view is a way to request and issue
>>>>>     multiple server-specific access tokens with a single
>>>>>     authorization process.
>>>>>
>>>>>     challenge to find a standardized protocol between
>>>>>     authorization server and resource server to exchange
>>>>>     authorization data. Depending on the token design
>>>>>         would like to start a re-chartering discussion.  We both
>>>>>         are currently attending the Internet Identity Workshop and
>>>>>         so we had the chance to solicit input from the
>>>>>         a) Are you interested in any of the above-listed items?
>>>>>         (as a reviewer, co-author, implementer, or someone who
>>>>>         would like to deploy). It is also useful to know if you
>>>>>         think that we shouldn't work on a specific item.
>>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 28 Oct 2011 09:28:13 +0900

Thanks George.

Just to clarify the intent of this I-D : this I-D proposes the JSON request
style to be adopted as part of OAuth so that the URI request parameters
could be omitted.

=nat

On Fri, Oct 28, 2011 at 5:24 AM, George Fletcher <[email-masked]> wrote:

> ensure that the request object was not modified in transit since the JSON
> request object can be signed. Agreed that it would be simpler if OAuth
> adopted the JSON request style.
>
> Thanks,
> George
>
> document? I would expect OpenId Connect to extend OAuth none-intrusively.
> This would mean to use the JSON document for OpenId connect specific
> parameters only. Alternatively, the JSON request style could be adopted as
> part of OAuth. Then, the URI request parameters could be omitted.
>
> regards,
> Torsten.
>
> ------------------------------
> *From: * John Bradley <[email-masked]> <[email-masked]>
> *To: *Torsten Lodderstedt<[email-masked]><[email-masked]>
> *Cc: *Nat Sakimura<[email-masked]> <[email-masked]>; OAuth WG
> <[email-masked]> <[email-masked]>
>  At least leave open the possibility of dealing with it at a higher level.
>
>  The argument has been made that you probably need to modify the library
> anyway to check that the duplicate parameters are a match.
>
>  It is essentially  a standardization of the method we are using in openID
> Connect to make signed requests to the Authorization server.
>
> necessarily duplicate the query parameters to keep it a valid OAuth request
> plus an extension.
>
>  Even if it doesn't wind up as a OAuth WG item it is probably worth people
> looking at it before the final openID spec is voted on.
>
>  Regards
> John B.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 29 Oct 2011 00:07:45 -0700

What if the access tokens come from different authoritative servers?

---

From: William Mills <[email-masked]>
Date: Sat, 29 Oct 2011 08:04:19 -0700 (PDT)

There's a problem here, which I think Eran's proposal of differentiating with scopes solves that should be made explicit, to whit, how does the client know which token to use in a specific context.  We have two options:  one is to specify different scopes, and the other is to use different token types.  

In the use case presented where it's different security levels  would just choose to go with the more secure MAC token in all cases, but it's probably worth noting how to do this.

-bill

________________________________
From: Dick Hardt <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: OAuth WG <[email-masked]>; Dan Taflin <[email-masked]>
Sent: Saturday, October 29, 2011 12:07 AM
Subject: Re: [OAUTH-WG] Rechartering

---

From: John Bradley <[email-masked]>
Date: Sat, 29 Oct 2011 12:31:08 -0300

Some may argue that MAC tokens are not necessarily more secure:)  

Eran's solution may well be sufficient for MAC (i still think downs scoping is necessary if symmetric keys are used),  however there are people using BEARER who encode information into signed tokens.

Those people also use the implicit flow.  There is no option at the moment other than returning multiple tokens.

John B.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 31 Oct 2011 14:17:26 -0700

That's a whole different issue as this is about talking to a single server retuning two tokens with different scopes.

EHL

________________________________________
From: Dick Hardt [[email-masked]]
Sent: Saturday, October 29, 2011 12:07 AM
To: Eran Hammer-Lahav
Cc: Dan Taflin; OAuth WG
Subject: Re: [OAUTH-WG] Rechartering

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 31 Oct 2011 21:56:06 +0000

Could be 2 tokens that still fulfill the same scope just that each token is a subset of the requested scope.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, October 31, 2011 2:17 PM
To: Dick Hardt
Cc: OAuth WG; Dan Taflin
Subject: Re: [OAUTH-WG] Rechartering

EHL

On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote:

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Dan Taflin
>> multiple access tokens with a single authorization process. The use 
>> case for my company is to segment operations into two main 
>> categories: protected and confidential. (A possible third category, public, would not require any authorization at all).
>> involve passing user data, like user registration or e-commerce. We 
>> would like to protect each category of operations with distinct 
>> tokens: a general-use token for protected operations, and a secure token for confidential operations.
>>
>> issued, but there is no way to obtain a new token with a completely 
>> different scope without doing the full oauth dance a second time.
>>
>> Dan
>>
>> missing from my point of view and explain some thoughts how to fill the gaps.
>>
>> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in 
>> many places, and used by different but deployment-independent clients.
>> read, write, send) and their relation to the resource types and 
>> It is interesting to note, that such a mechanism would allow us to 
>> get rid of secret-less clients and the one-time usage requirement for 
>> authorization codes.
>>
>> we MUST find another way to prevent token phishing by counterfeit resource servers.
>>
>> to run multiple instances of the same service within a single deployment.
>>
>> is a way to request and issue multiple server-specific access tokens with a single authorization process.
>>
>> existing core. In my opinion, a core enhancement would be easier to handle and more powerful.
>> If others support this topic, I would be willed to submit an I-D 
>> standardized protocol between authorization server and resource 
>> server to exchange authorization data. Depending on the token design 
>> some
>>> solicit input from the participants. This should serve as a discussion starter.
>>>