Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt

From: [email-masked]
Date: Sun, 05 May 2013 12:45:05 -0700

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-10.txt
	Pages           : 25
	Date            : 2013-05-05

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-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Richer, Justin P." <[email-masked]>
Date: Sun, 5 May 2013 19:52:20 +0000

Handful of minor changes in this revision, including tightening the language around scopes and adding an absolute-URI based mechanism for extending token_endpoint_auth_method (no registry, still). No normative changes beyond removing an unreachable error state. (Thanks, Nov.) Please check the diffs, we welcome feedback. I personally think this is really getting close to final.

 -- Justin

On May 5, 2013, at 3:45 PM, <[email-masked]>
 wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 6 May 2013 15:39:44 +0000

In spite of what John seems to think, that dependency was never there. The whole discovery process is related, but separate, from registration. It could happen using OIDC, it could happen with Bill Mills's LRDD link types, it could happen with Nat's proposed HAL-based system, it could happen by the developer going to the service provider's documentation page and reading a bunch of text (which is what happens with large OAuth providers today) -- it ultimately doesn't matter. 

And I think that the Dynamic Registration protocol that we have here is robust against that kind of diversity. Let's take the token_endpoint_auth_method parameter as an example. Let's say a client shows up to a service it's just discovered -- through whatever means, we don't actually care. This client either has some idea of what auth methods the server supports (through a discovery mechanism) or it doesn't. If it does, it will also know which methods it supports and it can pick one. If it doesn't, it will still know which methods it supports and will just pick one. The server will then take that information and do one of three things:

1) Accept what the client proposes and use that. This is of course the ideal situation where everybody gets what they want, and this can be brought about more often by a good discovery process.
2) Reject what the client proposes with an error code (invalid_client_metadata would cover this). The client then has to re-register with a different value or just give up because the two systems are using different auth methods that can't be reconciled.
3) Ignore what the client proposes and return the server's preferred method. The client can then, in turn:
  a) Accept what the server returns and use that, if it supports it. This is also ideal because everybody is happy again.
  b) Reject what the server returns and either try the registration again with another value or give up.
  c) Ignore what the server returns and fail when doing a token request. This would be a dumb thing for a dumb client to do. 

Alternatively, the client could just not mention it and have the server dictate what method it will use, and the client will either accept, reject, or ignore it. This process applies to every parameter in the system, from something innocuous as the client's TOS uri to something as security-critical as the redirect_uri (which gets its own special error message). 

I think that the assumption of full automation for all clients to all servers is a red herring in the OAuth world for the simple fact that the API that's being accessed/protected isn't going to be universally compatible anyway. I agree fully that a well-specified service discovery is important and we should, as a working group, help figure out what that looks like. As mentioned above, several of us already are. But I don't think it's helpful to conflate the registration and discovery processes and turn them into some kind of negotiation system. I think we can do a good job of making it widely useful without that.

 -- Justin

On May 5, 2013, at 1:05 PM, Phil Hunt <[email-masked]>
 wrote:

> Justin,
> 
> Has the assumption of a discovery service defined by OIDC been removed?
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
> 
> 
> 
> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 6 May 2013 11:56:45 -0700

Justin,

What you describe, though good intentioned, seems like a lot of complexity without getting an actual benefit. I would rather not have token_endpoint_auth_method at all.

Think about someone writing a general purpose SCIM client or OIDC client.  Site as uses method 1 and 2, site b supports 2,3 and 4.  Site c only 5 and 6.  So if each site is willing to negotiate authn, how has this developer's coding been reduced? The developer will end up having to implement all popular methods regardless of discovery or the ability of the client to select. In fact, they have to do all the logic you describe below AND implement all methods.

I have also thought through, does it matter since it is optional?  I think it does. If servers just ignore the param most of the time, what value is there?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Josh Mandel <[email-masked]>
Date: Tue, 7 May 2013 10:09:49 -0700

As I understand it (corrections welcome!) rfc6749 says that public clients:

1.  are defined functionally, as clients "incapable of maintaining the
confidentiality of their credentials" [section 2.1]
2.  "MAY establish a client authentication method" if the server allows.
e.g. client password auth [section 2.3]

Given 1 and 2, it's technical possible for a public client to be assigned a
(not-so-)secret that it uses not for authentication per se, but merely to
go through the motions of client password auth.

(How) Does dyn-reg support the registration of a public client that (for
whatever reason -- code re-use?) seeks to use a client authentication
method? It seems to me that, given the current draft, a registration server
couldn't tell such a client from a confidential client  (
token_endpoint_auth_method, grant_types, and response_types would be
indistinguishable).

Is this use case out of scope?  If so, the spec might benefit from a note
to that effect.  If not, an explicit flag at registration time (conveying
the app's explicitly asserted "public" vs. "confidential" status) might
help servers make better decisions.

  -Josh

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 7 May 2013 20:55:38 +0000

A true public client doesn't have a client_secret or its equivalent, so it would have token_endpoint_auth_method = none. A confidential client can't use the implicit flow (since you can't send a client_secret to the auth endpoint), so there's a bit of overlap there.

Would it be useful to have an explanatory paragraph or table to this effect in the draft? I'm currently thinking that'd be a bit overkill, but I'd definitely rather it be clear and unambiguous.

 -- Justin

On May 7, 2013, at 10:09 AM, Josh Mandel <[email-masked]<mailto:[email-masked]>>
 wrote:

1.  are defined functionally, as clients "incapable of maintaining the confidentiality of their credentials" [section 2.1]
2.  "MAY establish a client authentication method" if the server allows. e.g. client password auth [section 2.3]

Given 1 and 2, it's technical possible for a public client to be assigned a (not-so-)secret that it uses not for authentication per se, but merely to go through the motions of client password auth.

(How) Does dyn-reg support the registration of a public client that (for whatever reason -- code re-use?) seeks to use a client authentication method? It seems to me that, given the current draft, a registration server couldn't tell such a client from a confidential client  (token_endpoint_auth_method, grant_types, and response_types would be indistinguishable).

Is this use case out of scope?  If so, the spec might benefit from a note to that effect.  If not, an explicit flag at registration time (conveying the app's explicitly asserted "public" vs. "confidential" status) might help servers make better decisions.

  -Josh

On Sun, May 5, 2013 at 12:45 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 9 May 2013 20:51:15 +0000

So if that's the case -- you've got a client that can't keep a secret that has a secret -- you do one of the normal auth methods (like client_secret_basic) and call it a day. I don't think it makes any sense, and the language below is really less about client secrets and more about assertions and other methods of authentication that otherwise "public" clients could use. DynReg makes it so that the client_secret is now a runtime secret, so we're already outside the core definitions of public/confidential clients anyway.

 -- Justin

On May 9, 2013, at 8:41 AM, Josh Mandel <[email-masked]<mailto:[email-masked]>>
 wrote:

> A true public client doesn't have a client_secret or its equivalent, so it would have

If this is the case,  then my premise #2 is wrong -- and in that case my  concern about dynamic registration disappears.  But if so: what is the quoted bit of 2.3 *supposed* to indicate? (If not that a public client might,  in some scenarios, be given a client_secret with the explicit expectation that it won't be kept secret and the stipulation that it mustn't be relied upon for authentication... )

Thanks!

  - Josh

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 14:44:24 -0700

Justin,

Just to progress towards resolving this issue, what I would like to understand is how specifying authentication type makes things simpler or more inter-operable. I'm concerned that the logic you proposed early in the thread is a lot more complexity.  I would prefer just having the server tell the client what authentication it MUST use.

As an alternative, the negotiation for credential method/type could occur during the initial developer registration of the app.  As in your "blue button" health case (did I remember that right), the initial registration JWT would be used in the dynamic registration and allow the registration server to observe any previously negotiated client preferences OOB of this spec.  Or, are you saying that individual instances have some need to change authentication types on a per deployment basis independent of what the associated authorization server wants them to use? If so what is it?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 9 May 2013 21:57:05 +0000

Part of my argument for leaving this parameter in is exactly the use case that you're saying: the client doesn't tell the server anything but the server tells the client what it must use to authenticate. That's already possible using what's there. But I'm loathe to pull out this particular piece of metadata as non-parallel and separate from the rest of the parameters. 

The whole negotiation for this or any other parameter can happen at least partially out of band, for instance as part of the discovery process. In Blue Button+ (reference for others, here: http://blue-button.github.io/blue-button-plus-pull/), you could either pre-register it or you could do it per-instance. You'd probably pre-register this parameter in most cases though because the nature of the app's capabilities won't really change. 

What I think this parameter gives you is a *chance* for things to go right or stop early before they go horribly wrong later in the process where the stakes are higher. All of the if-then steps I listed out below still exist if the client can't tell its preferred auth method to the server in-band during registration, the decisions just happen at a different times where it's harder to recover programmatically. And since it's an optional parameter on both sides, people who don't want to deal with the logic to process it don't have to do anything with it.

 -- Justin

---

From: John Bradley <[email-masked]>
Date: Thu, 9 May 2013 15:17:03 -0700

The client needs to be able to say only use a particular auth method to disallow the Authorization server from providing a weaker method to an attacker.  

This is a required parameter to allow a Authorization server to support high and low LoA clients dynamically.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 15:32:25 -0700

Giving the client the choice lets the client choose lower LoA and downgrade.  Surely it is the server that is taking the risk so the server has the right to set the requirements.

Why would a server tolerate multiple levels of LoA from the same client application?  Why is that needed?

If a server allows 2 and 3, then all clients will choose 2 -- or at the very least your overall security drops to 2.  This is not good.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 9 May 2013 15:47:09 -0700

Consider if you will a world where IdP support multiple LoA.

This allows a RP to register the method required for there use case.

If a Client requires the asymmetrically signed JWT assertions rather than http basic,  it doesn't want the Authorization server accepting http_basic for it's client_id.

The reason a client/RP would want to specify multiple LoA is the same reason they may wan to in SAML or other protocols.

The issue is more that different clients will have different security requirements and this allows them to dynamic register those.

If you allow 2 and 3 the one that need 3 will specify that.

John

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 15:58:34 -0700

You seem to now be talking about SAML endpoints rather than OAuth endpoints.

I think you are confusing what the client gets back from the AS in terms of the OAuth protocol vs.  how the client authenticates to the AS.  The parameter in question isn't about what assertions the AS returns to the client.  The case is about what credential the client must use with the AS to satisfy a particular AS's requirements. 

I haven't heard a reason for clients to be able to downgrade.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Thu, 9 May 2013 16:03:01 -0700

The issue is not allowing fake clients to dynamically downgrade, where the AS supports multiple methods.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 16:37:38 -0700

How does NOT allowing clients to choose authn type allow them to downgrade. I am saying there is NO value in allowing this and that the parameter needs to be removed. 

Phil

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 16:46:39 -0700

Maybe i am not being clear. I feel the parameter must not be in the dyn reg request.  The parameter should be in the response so that the client has no choice and no ability to downgrade. 

Phil

---

From: John Bradley <[email-masked]>
Date: Thu, 9 May 2013 16:55:37 -0700

The downgrade is at runtime not at registration.  It is signalling the methods the RP doesn't want the AS to support for the client_id.

We are not getting anywhere on this.  The parameter is required for dynamic registration of higher security clients at AS that support multiple token_endpoint authentication types.

John

---

From: Phil Hunt <[email-masked]>
Date: Thu, 9 May 2013 17:19:09 -0700

Well this is a last call discussion. So we have to get somewhere don't we?

Phil

---

From: John Bradley <[email-masked]>
Date: Thu, 9 May 2013 17:24:45 -0700

Yes but the two of us going back and forth seem not to be making progress.

I am still at the IDESG meeting if you want to get together.