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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
