rization for
>>> that client. The user then gets a new copy of that client (perhaps
>>> a new computer) and authorizes it. Whoops. Now all those
>>> invalidated tokens are valid again because the authorization tuple
>>> exists. Except now the issue date on
ach request had a unique type, now we
> are back to guessing what is requested, like in WRAP.
I am just wondering why having a separate endpoint for this isn't
enough. I would rather map another library call to another endpoint
instead of relying on guessing on the contents. T
t 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
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://w
gistration protocol.
>>>
>>>
>>>
>>> The IETF Secretariat.
>>>
>>>
>>
>>
>> Eve Maler http://www.xmlgrrl.com/blog
>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler
>>
>> __
on_date:
>>>>> 2010-08-10 WG ID: Independent Submission Number_of_pages:
>>>>> 20
>>>>>
>>>>> Abstract: This specification proposes an OAuth Dynamic Client
>>>>> Registration proto
n 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.
uirements like also sending some
metadata information from the client to the server (as you'd normally do
with manual registration). We also would probably prefer having a separate
spec we can point to for registration (probably the same for discovery).
best regards,
Christian
--
Christian Scholz,
