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 phil.h...@oracle.com 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Phil Hunt > Sent: Thursday, October 27, 2011 10:49 AM > To: tors...@lodderstedt.net > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Rechartering JSON based request. > > 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 > phil.h...@oracle.com > > > > > > On 2011-10-27, at 10:33 AM, tors...@lodderstedt.net 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. > Gesendet mit BlackBerry® Webmail von Telekom Deutschland > > From: John Bradley <ve7...@ve7jtb.com> > Date: Thu, 27 Oct 2011 13:52:31 -0300 > To: Torsten Lodderstedt<tors...@lodderstedt.net> > Cc: Nat Sakimura<sakim...@gmail.com>; OAuth WG<oauth@ietf.org> > 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. > > It is mostly a case of trying to fit in to the existing OAuth work and > libraries. > > John B. > > On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: > > > why is it neccessary to duplicate the OAuth request parameters? > > Am 27.10.2011 00:31, schrieb John Bradley: > 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. > > Am 22.10.2011 16:00, schrieb Nat Sakimura: > 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 > <tors...@lodderstedt.net> 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) > - 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 <hannes.tschofe...@gmx.net>: > > > 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 > > _______________________________________________ > 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 > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > _______________________________________________ > 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
