Hi!

Am 11.08.10 16:36, schrieb Stefanie Dronia:
> 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?

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.

>     # 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.

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.

> # 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?

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
> printed.

Right, thanks!

-- Christian

> 
> Regards,
> Stefanie
> 
> Am 10.08.2010 21:31, schrieb Eve Maler:
>> 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<idsubmiss...@ietf.org>
>>> Date: 10 August 2010 12:23:59 PM PDT
>>> To:e...@xmlgrrl.com
>>> Cc:c...@comlounge.net,m.p.machu...@ncl.ac.uk
>>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>    
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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

Reply via email to