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
