Interesting use case, and not dissimilar to some others I've heard. How would
you go about tracking this? Why would the instances need to know about each
other?
One possible approach would be to use a common initializing Request Access
Token that is used to call client_register on all instances
Hi George,
I am with you and support your suggestion. An "invalid_parameter"
error code would be a practical solution that would allow to
distinguish between token usage and token as parameter.
Regards
Peter
Am 09.01.13 16:40, sc
One issue is that some of the top level elements like redirect_uri may be
arrays. I wouldn't want to start specifying partial replacement for that.
DynReg should replace all of an array or object. I suspect that is the intent
anyway.
I see the benefit of returning the entire configuration in
Hi all,
based on a conversion with one of our developers I would prefer the DynReg
style.
regards,
Torsten.
Am 09.01.2013 um 21:05 schrieb "Richer, Justin P." :
> It's been a few days now and I haven't seen any traffic from the group about
> this at all, so I'll just come out and ask for opin
Igor,
The question is not whether to remove the parameter from the spec, but
rather what one would expect as a "default" behavior from a "normal"
OAuth2 provider. Option1 says that the default is to leave it out of the
response. But it'll still be there in cases where the AS and PR know
what
I chime in in support of option 1. Rationale: nothing is worse than
the presence of an obscure parameter. (Not only it pollutes the
environment, but it is a potential attack vector.) So rather than invent
an acceptable value for it, I would remove it.
Igor
On 1/10/2013 11:59 AM, George Fl
the
>>>>>>> token's value as a lookup key.
>>>>>>
>>>>>> I probably didn't describe well what I meant. I would suggest to
>>>>>> return a JWT claim set from the introspection endpoint. That way
>>>>>> one could use the same claims (e.g. ia
That makes sense as well:)
Hopefully some others will chime in as I think this is an area that
could use some "best practice" guidelines.
Thanks,
George
On 1/10/13 11:53 AM, Justin Richer wrote:
I'm leaning towards 1 because the client is more the "authorized
presenter" of the token, not its
I'm leaning towards 1 because the client is more the "authorized
presenter" of the token, not its audience.
-- Justin
On 01/10/2013 11:52 AM, George Fletcher wrote:
So in the default case I see two options for an AS that wants to
implement this endpoint...
1. Omit 'audience' from the respon
So in the default case I see two options for an AS that wants to
implement this endpoint...
1. Omit 'audience' from the response: The rationale here is that there
really isn't an explicit audience and what clients need to protect
against things like "confused deputy" is the client_id which is
Use cases that I was asked to collect are detailed here:
http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html
-- Justin
On 01/10/2013 08:32 AM, Hannes Tschofenig wrote:
We will have our next OAuth conference call tomorrow at 1pm EST (for roughly
one hour).
John & Nat kindly offe
In traditional OAuth, there really isn't a baked-in notion of 'audience'
since the AS<->PR connection is completely out of scope. However, in
practice, when you've got more than one PR per AS, you'll have some
notion of 'audience'. It's definitely possible to handle this with
'scope', especiall
We will have our next OAuth conference call tomorrow at 1pm EST (for roughly
one hour).
John & Nat kindly offered their conference bridge:
https://www3.gotomeeting.com/join/695548174
Here are the notes from the last meeting:
http://www.ietf.org/mail-archive/web/oauth/current/msg10279.html
Here
Hi
On 09/01/13 21:47, George Fletcher wrote:
I had the same confusion about "what is 'audience' in OAuth?" today
working on a completely different project.
I think for the default OAuth2 deployment, scopes take the place of
audience because the scopes identify the authorization grant(s) at the
r
14 matches
Mail list logo
