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 <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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
