Subject: [OAUTH-WG] Proposal for OAuth dynamic client registration

From: Eve Maler <[email-masked]>
Date: Tue, 10 Aug 2010 12:31:44 -0700

Folks-- The UMA group has produced the following I-D as input to the OAuth discovery/registration/binding discussion.  We wanted to set forth our requirements (knowing that there may be other requirements from the wider community) and propose some solutions that meet them.  If further discussion seems to warrant an updating of this draft, we're happy to do that.  (If you have interest in getting involved in UMA-specific work, feel free to drop me a note.)

	Eve

http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: 10 August 2010 12:23:59 PM PDT
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 
> 
> 
> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully submitted by Eve Maler and posted to the IETF repository.
> 
> Filename:	 draft-oauth-dyn-reg-v1
> Revision:	 00
> Title:		 OAuth Dynamic Client Registration Protocol
> Creation_date:	 2010-08-10
> WG ID:		 Independent Submission
> Number_of_pages: 20
> 
> Abstract:
> This specification proposes an OAuth Dynamic Client Registration
> protocol.
> 
> 
> 
> The IETF Secretariat.
> 
> 

Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler

---

From: Lukas Rosenstock <[email-masked]>
Date: Wed, 11 Aug 2010 10:20:18 +0200

Nice to see this draft!
I've just read it and would like to provide some feedback:

1) redirect_url vs. redirect_uri: In different flows, different terms have
been used. I think that should be consistent and it should be uri.

2) Data formats for requests: This spec uses JSON for everything. The core
OAuth (draft 10) uses encoded forms for the request and JSON for the
response. Why not make it consistent with that? I don't see any requirement
to actually POST in JSON as well.

3) The OpenID Connect proposal* includes something similar. For the
response, they have added a few more parameters along with client_id and
client_secret. To quote it:
- expires_in - The number of seconds that this id and secret are good for or
"0" if it does not expire.
- flows_supported - A comma separated list of the OAuth 2.0 flows which this
server supports. The server MUST support the Web server (web_server) and
User-Agent (user_agent) flows.
Don't you think those would be useful?! Also, so far there's no information
(or I didn't see it ...) on whether dynamic registration should be
considered temporary or permanent.

Thanks and regards,
 Lukas Rosenstock

[*] http://openidconnect.com/

2010/8/10 Eve Maler <[email-masked]>

> Folks-- The UMA group has produced the following I-D as input to the OAuth
> discovery/registration/binding discussion.  We wanted to set forth our
> requirements (knowing that there may be other requirements from the wider
> community) and propose some solutions that meet them.  If further discussion
> seems to warrant an updating of this draft, we're happy to do that.  (If you
> have interest in getting involved in UMA-specific work, feel free to drop me
> a note.)
>
>        Eve
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 12:40:53 +0200

Eve,

thank you for writting this document. I consider it a good starting point for a discussion about client registration and discovery. Will you propose this as a WG item?

My comments & questions:

You propose a host-meta based discovery of the registration endpoint on the authz server. Could this mechanism be used for discovering all AS endpoints, e.g. tokens and end-user authorization?

How is a UMA requestor envisioned to discover the auth server?

I think host-meta based client discovery could be to limited since it does not allow (at least in my understanding) to serve different clients (or their home web apps) on the same host. What about using JRD or XRD? This would allow for a client-URL-related discovery.

What means for authentication a client against its home web app. do you envision?

regards,
Torsten.

Am 10.08.2010  um 21:31 schrieb Eve Maler <[email-masked]>:

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 14:17:09 +0200

> I think host-meta based client discovery could be to limited since it does not allow (at least in my understanding) to serve different clients (or their home web apps) on the same host. What about…

I meant LRDD, seems I got lost in the discovery universe for a moment :-) I took a look into the latest host-meta draft. host-meta processors seem to directly support LRDD. So everything is fine with me.

regards,
Torsten.

---

From: Stefanie Dronia <[email-masked]>
Date: Wed, 11 Aug 2010 16:36:21 +0200

Hallo Eve,

I read your proposal, too. Thanks for providing it.

Some questions:
# first part of chapter 2
     # enchanced OAuth RS, AS and client are mentioned. Does the 
enhancement just denote, that they support dynamic client registration 
or have any further requirements to be fulfilled by them?
     # The text is "... use an access token in approximately the normal 
OAuth fashion,...": What do you mean by "approximately" in this context? 
As far as I understood, after client registration, OAuth flows are 
performed as defined.
# For registration, the client has to give its URL (parameter client_url 
in registration request). May it be used later for OAuth callback url, 
e.g. if client registration with pushed metadata is selected?

And just a typo: Example chapter 7.1: "url" instead of "client_url" is 
printed.

Regards,
Stefanie

Am 10.08.2010 21:31, schrieb Eve Maler:
>> From: IETF I-D Submission Tool<[email-masked]>
>> To:[email-masked]
>> Cc:[email-masked],[email-masked]

---

From: Christian Scholz <[email-masked]>
Date: Wed, 11 Aug 2010 16:51:07 +0200

Hi!

Thanks for the feedback! :-)

Am 11.08.10 10:20, schrieb Lukas Rosenstock:
> 1) redirect_url vs. redirect_uri: In different flows, different terms
> have been used. I think that should be consistent and it should be uri.

I agree, there is also a client_url which might also be client_uri then.

> 2) Data formats for requests: This spec uses JSON for everything. The
> core OAuth (draft 10) uses encoded forms for the request and JSON for
> the response. Why not make it consistent with that? I don't see any
> requirement to actually POST in JSON as well.

Except maybe length. It might depend on how much metadata in the end
will be transferred from client to server (eventually with a signature)
but a good point indeed.

> - expires_in - The number of seconds that this id and secret are good
> for or "0" if it does not expire.

We have that in the push version but not in pull where it probably
should be added.

> - flows_supported - A comma separated list of the OAuth 2.0 flows which
> this server supports. The server MUST support the Web server
> (web_server) and User-Agent (user_agent) flows.
> Don't you think those would be useful?! Also, so far there's no
> information (or I didn't see it ...) on whether dynamic registration
> should be considered temporary or permanent.

I wonder if this should be part of the client registration response or
maybe part of the general AS metadata as I assume it's more of a global
attribute and not one per client.

As for temporary/permanent wouldn't the server decide based on the
expires_in attribute?

In UMA though we are probably more interesting in long term
relationships to be able to identify clients over time.

cheers,

Christian

> 2010/8/10 Eve Maler <[email-masked] <mailto:[email-masked]>>
> 
>     Folks-- The UMA group has produced the following I-D as input to the
>     OAuth discovery/registration/binding discussion.  We wanted to set
>     forth our requirements (knowing that there may be other requirements
>     from the wider community) and propose some solutions that meet them.
>      If further discussion seems to warrant an updating of this draft,
>     we're happy to do that.  (If you have interest in getting involved
>     in UMA-specific work, feel free to drop me a note.)
> 
>            Eve
> 

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                                    http://mrtopf.de/blog
Hanbrucher Str. 33                             http://twitter.com/mrtopf
52064 Aachen                                             Skype: HerrTopf
Tel: +49 241 400 730 0                                  [email-masked]
Fax: +49 241 979 00 850                                      IRC: MrTopf

Podcasts:
Der OpenWeb-Podcast (http://openwebpodcast.de)
Data Without Borders (http://datawithoutborders.net)
Politisches: http://politfunk.de/
Technical: http://comlounge.tv/

---

From: Christian Scholz <[email-masked]>
Date: Wed, 11 Aug 2010 17:13:09 +0200

Hi!

Am 11.08.10 12:40, schrieb Torsten Lodderstedt:
> Eve,
> 
> thank you for writting this document. I consider it a good starting
> point for a discussion about client registration and discovery. Will
> you propose this as a WG item?

I think that's the plan as it is more related more to OAuth in genral
than UMA specific.

> My comments & questions:
> 
> You propose a host-meta based discovery of the registration endpoint
> on the authz server. Could this mechanism be used for discovering all
> AS endpoints, e.g. tokens and end-user authorization?

I would think so. We concentrated more on the one endpoint we need but
it makes sense to discover all of the necessary endpoints that way. So
some merge of ideas floating here about general discovery might be useful.

> How is a UMA requestor envisioned to discover the auth server?

On the Host side the user can tell it which AM (in UMA terms it's an
Authorization Manager, some sort of extended AS) to use or it might be
discovered via webfinger or similar means.

The process for requesters is up to discussion a bit right now. In my
prototype the Host is telling the Requester which AM is registered to
the resource it tries to access. Then client registration can start from
there.

> I think host-meta based client discovery could be to limited since it
> does not allow (at least in my understanding) to serve different
> clients (or their home web apps) on the same host. What about using
> JRD or XRD? This would allow for a client-URL-related discovery.

You are right. The question here might be if the LRDD part is being used
or if maybe directly point to the client spec which would save one
redirection. Not sure if we need to add a type field in this case, too
(e.g. if JRD or XRD). I would favour to use only one format (JRD) though.

-- Christian

> regards, Torsten.
>> Folks-- The UMA group has produced the following I-D as input to
>> the OAuth discovery/registration/binding discussion.  We wanted to
>> set forth our requirements (knowing that there may be other
>> requirements from the wider community) and propose some solutions
>> that meet them.  If further discussion seems to warrant an updating
>> of this draft, we're happy to do that.  (If you have interest in
>> getting involved in UMA-specific work, feel free to drop me a
>> note.)
>> 
>> Eve
>> 
>>> From: IETF I-D Submission Tool <[email-masked]> Date: 10
>>> August 2010 12:23:59 PM PDT To: [email-masked] Cc:
>>> [email-masked], [email-masked] Subject: New Version
>>> Notification for draft-oauth-dyn-reg-v1-00
>>> 
>>> 
>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been
>>> successfully submitted by Eve Maler and posted to the IETF
>>> repository.
>>> 
>>> Filename:     draft-oauth-dyn-reg-v1 Revision:     00 Title:
>>> OAuth Dynamic Client Registration Protocol Creation_date:
>>> 2010-08-10 WG ID:         Independent Submission Number_of_pages:
>>> 20
>>> 
>>> Abstract: This specification proposes an OAuth Dynamic Client
>>> Registration protocol.
>>> 
>>> 
>>> 
>>> The IETF Secretariat.
>>> 
>>> 
>> 
>> 
>> Eve Maler http://www.xmlgrrl.com/blog 
>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler
>> 
>> _______________________________________________ OAuth mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________ OAuth mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth

Podcasts:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 17:31:52 +0200

> the resource it tries to access. Then client registration can start from

How does the Host tell the requester? I would imagine using host-meta, too.

regards,
Torsten.

---

From: Christian Scholz <[email-masked]>
Date: Wed, 11 Aug 2010 17:40:38 +0200

> How does the Host tell the requester? I would imagine using host-meta, too.

The URI of the AM's resource token endpoint is included in the
WWW-Authenticate header. From there on it's host-meta discovery for all
necessary data. So yes.

(and the Host knows which AM to include because it knows which resource
was registered with which AM)

Very rough version:
http://mrtopf.clprojects.net/uma/draft-uma-core.html#anchor9

-- Christian

Podcasts:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 17:45:05 +0200

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 11 Aug 2010 17:47:45 +0200

> http://mrtopf.clprojects.net/uma/draft-uma-core.html#anchor9

So sending an unauthorized request is the only way to discover the AM?

regards,
Torsten.

---

From: Christian Scholz <[email-masked]>
Date: Wed, 11 Aug 2010 18:22:14 +0200

Hi!

> or have any further requirements to be fulfilled by them?

These are mostly examples from the User Managed Access (UMA) Working
Group where we use components which have to do a bit more than simple
OAuth. Out of this came the need for dynamic client registration which
we thought might be useful in other OAuth contexts as well.

So regarding the actual client registration they do not need to have
further requirements other than the client registration capabilities
described. In the final version we might want to get rid of the UMA
specific text in order to prevent confusion.

> As far as I understood, after client registration, OAuth flows are

Yes, again this relates to our UMA use cases where later on (after
client registration) those components need to do a bit more. For this
spec though this is irrelevant.

> e.g. if client registration with pushed metadata is selected?

Those parameters basically should represent what you otherwise would
enter into a registration form like http://dev.twitter.com/apps/new
Thus there probably need to be more fields in there but website url (or
client_url) and callback_url should probably be 2 different attributes.

The question regarding the client metadata is how much information
really is needed. For manual registration the server can ask as much as
it wants. For automatic registration I would like some basic set of
attributes, some maybe being optional. The question might be which ones
to take.

> And just a typo: Example chapter 7.1: "url" instead of "client_url" is

Right, thanks!

-- Christian

>> we're happy to do that.  (If you have interest in getting involved in
>> UMA-specific work, feel free to drop me a note.)
>>
>>     Eve
>>
>>> successfully submitted by Eve Maler and posted to the IETF repository.
>>>

Podcasts:

---

From: Eve Maler <[email-masked]>
Date: Wed, 11 Aug 2010 10:12:23 -0700

Great comments; thanks to Christian for responding.  To answer just a couple of more points that I don't think got addressed yet:

Yes, we would very much like for dynamic client registration to become a work item of this group.  (Do we need to take any steps other than stating so in this email?)

And, I've written to this list a couple of times in the past, describing ways in which UMA builds on top of OAuth (it's basically a series of profiles and extensions, any of which I'm willing to believe might have value to a wider community on its own), but it seems like a summary at this juncture would be a good idea.  If OAuth has two steps, "get a token" and "use a token", UMA has three, adding one at the beginning:

- Step 1: trust a token: Authorizing user introduces host to authorization manager as an OAuth client of it.  The host and AM need to acquaint themselves with each other in the context of this user to support the user's setting of policies at the AM that will govern the giving out of requester access tokens for the host's protected resources later.  The specifics involve the host actually getting its own access token that it can use at a host-specific set of endpoints at the AM (it's basically an embedded instance of OAuth).  As necessary, the dynamic client registration stuff comes in.

- Step 2: get a token: The requester approaches a protected resource, learns where to go to get an access token, and sets about trying to get it in mostly a normal fashion (engaging in dynamic client registration as necessary).  What UMA adds on top is that the AM can ask the requester to produce "claims" in support of proving its suitability for getting the token.  If the authorizing user had set policies that could be applied unilaterally in token issuance, great, but if the user had set policies that require the requester to (say) promise to adhere to the user's licensing terms, that can be provided in a claim.  (The mechanism is simple so far, but the implications are powerful...  We've been exploring legal considerations of authorizing access by fully autonomous parties.)

- Step 3: use a token: Requester wields token at host to get access.  What UMA adds on top is the host's ability to talk to the AM on a back channel to validate that token, to support minimal host implementations and fully dynamic host deployments.

We're still in the process of defining (and in some cases redefining) the various protocol bits, and welcome input and engagement from others if the use cases we're solving for float your boat.  If you want to see a full experimental implementation (soon to be open-sourced, I understand) in action, I-D coauthor Maciej and his crew are documenting their work at http://smartjisc.wordpress.com/.

	Eve

Eve Maler

---

From: Stefanie Dronia <[email-masked]>
Date: Thu, 12 Aug 2010 09:11:17 +0200

Hi Christian,

thanks for clarification.

Regards, Stefanie