[Openid-specs-ab] Dynamic Client Registration

Nat Sakimura sakimura at gmail.com
Mon Feb 4 19:10:09 UTC 2013


Apparently, I did not upload the right version.

I noticed at least some of the errors (in copy+paste) after initial
pointing out of Torsten and meant to have fixed them and uploaded them, but
I apparently did not.

I am travelling now but once I get to a suitable network connection etc., I
will upload the correct version.

Sorry for the confusion.

Nat

P.S. I thought I have sent  this message out before flying but apparently
it did not go out perhaps due to the spotty connection. I am in LAX now
waiting in a line for the security.

2013/2/4 Mike Jones <Michael.Jones at microsoft.com <javascript:;>>:
> Thanks for doing this.  It helps make apparent the current differences
> between the OAuth dynamic registration spec and the Connect dynamic
> registration spec.
>
>
>
> I’ve read the differences in your doc from the current Connect spec.  I
saw
> the following changes:
>
>   - Moved Terminology section out of Introduction

yes.

>
>   - Added several terminology definitions

yes.

>
>   - Deleted the “operation” parameter

yes.

>
>   - Deleted most of “rotate_secret”

had to remove all of them.

>
>   - Added Client Read Request (GET)

Yes. For discussion to be concrete.

>
>   - Added Client Delete Request (DELETE)

Yes. For discussion to be concrete.

>
>   - Added “Self URL”

Yes. For discussion to be concrete.

>
>   - Added “_links”

Yes. For discussion to be concrete.

>
>   - Removed “access_token” parameter from Client Registration and Update
> Request
>
>   - Undid the edits that addressed
>
https://bitbucket.org/openid/connect/issue/698/messages-12-terminology-inconsistent-use

I started to work off the local copy just by pulling and not updating it
seems :-( Will see the diff and re-apply them.

>
>   - Added two Editor’s Notes

Yes.

>
>   - Changed the Japanese client name

The original was a direct translation of My Application,
but that was sooo awkward because we really do not
say "my" in Japanese. So, I changed it to something
less awkward.

>
>   - Changed value of example registration_access_token
>
>   - Added “scope” to the example response (which isn’t defined in the
spec)
>
>   - Added “grant_type” to the example response (which isn’t defined in the
> spec)
>
>   - Removed these fields from the example response:
> token_endpoint_auth_method, application_type, redirect_uris, client_name,
> client_name_#ja-Jpan-JP, subject_type, sector_identifier_url,
> userinfo_encrypted_response_alg, userinfo_encrypted_response_enc
>
>   - Added issued_at
>
>   - Added client update example (that seems to be missing many parameters
> that were present in the registration request example)
>
>   - Changed the history entries for -14 and -08
>
>   - Changed where line breaks occur in many places in the XML source
(making
> diffing the .xml source quite difficult)
>
>
>
> If I missed any other changes, please let me know.  I haven’t diffed your
> edited version with the OAuth spec.  I assume many/most of the changes
made
> were made to match the OAuth draft.
>
>
>
> I was originally thinking that I would just review the changes and check
> them in, but there’s several changes that were made that haven’t been
> discussed by the working group and several changes that I believe were
> probably unintended, such as removing the fields from the example
response,
> adding undefined fields to the example response, reverting the issue #698
> changes, editing the history entries, and reformatting much of the XML,
so I
> decided not to check anything in based on this draft for now.  We should
> probably figure out which of these changes we should actually apply to the
> current draft and then check only those in.  Let’s talk about this on the
> Monday call.
>
>
>
> Also, we should talk about the proposal in your editor’s note to change
from
> a form encoded request to a JSON request.
>
>
>
> Thanks again for working to help us understand the ways in which the two
> specs are and aren’t aligned.
>
>
>
>                                                             Thanks again,
>
>                                                             -- Mike
>
>
>
> From: Nat Sakimura [mailto:sakimura at gmail.com <javascript:;>]
> Sent: Sunday, February 03, 2013 1:55 AM
> To: Mike Jones
> Cc: John Bradley; Vladimir Dzhuvinov / NimbusDS;
> openid-specs-ab at lists.openid.net <javascript:;> Group; Justin Richer
>
>
> Subject: Re: [Openid-specs-ab] Dynamic Client Registration
>
>
>
> Before getting this mail, I already added GET and DELETE.
>
> GET would not change the footprint at all, since its functionality is
> actually included in the POST (update).
>
> Normative text in the DELETE is just two lines so it can be easily added
or
> removed.
>
> Hard part is what John has pointed out - whether we really want to allow
the
> client to de-register.
>
>
>
> Here are the changed drafts:
>
>
http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html
>
>
http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml
>
>
>
> Nat
>
>
>
> 2013/2/3 Mike Jones <Michael.Jones at microsoft.com <javascript:;>>
>
> At least for Connect, I believe that we want to define only the operations
> that are essential to making Connect work.  So for instance, unregistering
> clients and retrieving registration state aren't actually necessary
> operations, and so I would not add these at the present time.  We want to
> keep the implementation footprint as small as possible.
>
>                                 -- Mike
>
>
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net <javascript:;>
> [mailto:openid-specs-ab-bounces at lists.openid.net <javascript:;>] On
Behalf Of John Bradley
> Sent: Saturday, February 02, 2013 9:20 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: openid-specs-ab at lists.openid.net <javascript:;> Group
> Subject: Re: [Openid-specs-ab] Dynamic Client Registration
>
> As you point out the client_id was removed when we went to OAuth
> authentication by the client for updates.
>
> I can see in a developer environment you may want to allow the master
token
> to modify any of the clients created by it thus requiring a separate
> client_id parameter.
> That is a reasonable reason to have that parameter.
>
> As far as de registering a client we start down a slippery slope of full
API
> management.
>
> I would not want to de register a app.  I could perhaps be convinced to
have
> a app state where you could have "enabled": false.
>
> That way an admin could disable a compromised client_id.
>
> However that raises questions like should an app be able to re enable
> itself?   Should that only be modifiable through the developer credential?
>
> Disabling is a bit of a can of worms so I am cautious, perhaps it belongs
in
> a client management extension.
>
> I am also receptive to the use of GET to inspect the current client config
> state without updating it.
>
> John B.
>
>
>
>
>
> On 2013-02-02, at 7:12 AM, "Vladimir Dzhuvinov / NimbusDS"
> <vladimir at nimbusds.com <javascript:;>> wrote:
>
>> Thank you John for explaining the story behind the current spec.
>>
>>
>>> I would like to remove rotate_secret as it is not restful for those
>>> that care and not especially useful.
>>
>> If we think in terms of REST and CRUD, is there a scenario where a
>> client may want to unregister? E.g. for an  IdP service that is paid
>> for?
>>
>> I also have a real case with a customer who wishes to add an optional
>> manual registration UI which should speak to the dynamic registration
>> endpoint for all requests:
>>
>> (1) client admin registering app,
>>
>> (2) client admin viewing existing registered app details,
>>
>> (3) client admin updating registered app details,
>>
>> (4) client admin deleting app registration.
>>
>>
>> The current endpoint spec that we have covers (1) and (3); (2) is
>> however only indirectly covered, using the update operation as a work
>> around, and (4) not at all.
>>
>> The missing "client_id" from update operations also makes it hard for
>> trusted third parties, such as the server hosting the manual reg UI,
>> to handle updates, because the access_token is directly tied to the
>> client_id and is used to derive it. If the client_id was specified
>> explicitly we could then issue an access_token the reg UI server for
>> all update operations.
>>
>>
>> Vladimir
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net <javascript:;>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <javascript:;>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <javascript:;>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
> --
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130205/c1430e40/attachment-0001.html>


More information about the Openid-specs-ab mailing list