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)
> - 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
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
