Hi,
Thanks for the feedback,
On 19/08/13 17:09, Justin Richer wrote:
Both of those make sense to me, and it mimics what "scope" does today.
Namely, clients can usually register for a list of scopes that they want
access to, then at authorization time they ask for a particular set to
be approved
Hi folks-- Just a reminder that the first draft the UMA group submitted on May
1, 2011 contained extensive requirements and use cases related to UMA's various
needs for dynamic client registration:
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00
When there was interest to pick up this
The reason I want to go over the cases is some seem to think uma and oidc are
all the use cases. As Justin points out they are very specific.
It doesn't seem like the dyn reg proposal is general enough to meet the wg
charter's intent. At least from what i recall of the discussion.
While i thi
Hi Phil,
>The assumption that client id must be issued by the sp seems wrong to
>me in many cases-- including oidc. 6749 does not make this restriction
>at all.
What do you mean? Grant type code requires a client_id in order to identify the
client at the AS's authz endpoint. Based on this da
See below
Phil
On 2013-08-19, at 22:34, Torsten Lodderstedt wrote:
> Hi Phil,
>
>
>
>
>> The assumption that client id must be issued by the sp seems wrong to
>> me in many cases-- including oidc. 6749 does not make this restriction
>> at all.
>
> What do you mean? Grant type code requires
Sorry i see my message still isn't that clear. I am saying there is no
requirement that a client directly obtain a client_id from the as service
provider. It is merely an assumption that has been made by dyn reg based on
typical use patterns to date.
It could be reasonable for a client to gen
