Hi Justin,
comments inline.
section 1.4
How is the client supposed to identify/distinguish authorization
servers? Based on the Client Registration Endpoint URI? Authorization
server identification is necessary in order to map client_ids to
authorization servers for clients, which are connected to multiple
authorization servers.
That's a great question -- but I think it's entirely dependent on how
discovery and configuration is set up for a client, which is
ultimately orthogonal to registration. The way that I've implemented
it in our client is based on the OpenID Connect discovery process,
which bases everything in the server's configuration off of an
"issuer" URL. It would be easy enough to point out here that discovery
and differentiation of different servers is out of scope.
At least this should be pointed out. I would rather prefer a definition
how to relate client_id and authz server.
I don't think your solution can be generalized for generic OAuth since
the issuer is only known to OpenID Connect clients. In my opinion, a
simple, generic concept could be based on the authorization server's
client registration URL. A more sophisticated approach would be to
introduce authorization server meta data discovery (as a subset of
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata),
which might contain an OAuth authz server id.
section 1.4.1 f
Why does the client secret expire while the access token ist still
valid? Secret and token are stored at the same
locations so an attacker may obtain both at once.
Secrets are used at the token endpoint, so the attack surface is
slightly different. Since you can only use the registration access
token at the registration endpoint, you can use it to rotate your
other credentials.
I understand the mechanism. I don't see the benefit given the _slight_
difference in attack surface. In my opinion, the only difference might
be on the server side, between HTTPS termination and actual endpoint
business logic. So it might limit the impact if an attacker, for
example, obtains client secrets from server log files. Is this threat
worth to use different credentials with different lifecycles?
"token_endpoint_auth_method"
What is the use case for dynamic registration of public clients? In
my opinion, public clients exist because OAuth 2.0 core does not
provided a mechanism to provision secrets to the different instances
of an installed/native app. Dynamic registration closes this gap, so
any installed app may retrieve a distinct secret.
This gap-closing is true for some classes of client that used to have
to be public, like many native apps. But there are still clients that
have no use for a client secret, like in-browser clients that use the
implicit flow. Now if these clients are also talking to multiple auth
servers, they'll each need a client_id at the auth server (because
there's no practical way to publish a "public" client ID to *all* auth
servers). A discussion in the security considerations about the
limitations and usefulness of this use case is probably worthwhile, so
I'll make a note to do that.
yes, clients using the implicit grant need a way to register. But they
don't use the token endpoint. As this is about token endpoint
authentication, I still don't see the need to have a "none" method there.
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send
the client secret. If an authorization server supports both, both
should work for any client. So are both methods treated differently?
I agree, and this was one of my original arguments for making this
field plural (or plural-able), but there hasn't been WG support for
that so far.
I'm not arguing to make it plural. I think the authentication method is
just "client_secret".
"jwks_uri"
What is this data used for? the OAuth JWT Bearer Token Profiles?
That's one, but it's really for any higher-level protocol that uses
signing and encryption. There are several out there that are using
JOSE on top of OAuth to do things, so we felt it was worthwhile to
have one standard place to have the client say "here's my public key".
ok, understood.
best regards,
Torsten.
-- Justin
best regards,
Torsten.
Am 24.05.2013 23:10, schrieb Richer, Justin P.:
New Dynamic Registration draft is published, incorporating much of
the discussion from the group this week.
Some normative changes that should have minimal impact:
- "expires_at" is now "client_secret_expires_at"
- "issued_at" is now "client_id_issued_at"
- creation of an IANA registry for token_endpoint_auth_method
- removal of two underdefined values from
token_endpoint_auth_method (client_secret_jwt and private_key_jwt),
these are now defined in an extension (OpenID Connect Registration)
And several editorial changes:
- new "client lifecycle" section that describes how different
kinds of clients can use the dynamic registration protocol, how a
client's credentials get refreshed, and the relationship between the
Client Identifier and the Client software
- new "registration tokens and credentials" section describing the
different kinds of tokens and credentials used in the registration
process, what they're for, and why they're all separate
- clarified the definitions of several fields like policy_uri and
tos_uri
Thanks for all the great feedback, and please keep the constructive
commentary coming!
-- Justin
On May 24, 2013, at 4:36 PM, <[email protected]>
wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Web Authorization Protocol Working
Group of the IETF.
Title : OAuth 2.0 Dynamic Client Registration Protocol
Author(s) : Justin Richer
John Bradley
Michael B. Jones
Maciej Machulak
Filename : draft-ietf-oauth-dyn-reg-11.txt
Pages : 34
Date : 2013-05-24
Abstract:
This specification defines an endpoint and protocol for dynamic
registration of OAuth 2.0 Clients at an Authorization Server and
methods for the dynamically registered client to manage its
registration.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
