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 <mailto: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
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
