>>> parameters only. Alternatively, the JSON request style could be adopted as
>>> part of OAuth. Then, the URI request parameters could be omitted.
>>>
>>> regards,
>>> Torsten.
>>> Gesendet mit BlackBerry® Webmail von Teleko
Sakimura; OAuth WG
*Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
Hopefully to make it more compatible with existing OAuth 2 libraries.
At least leave open the possibility of dealing with it at a higher
level.
The argument has been made that you probably need to modify the
27 Oct 2011 13:52:31 -0300
> *To: *Torsten Lodderstedt
> *Cc: *Nat Sakimura ; OAuth WG
>
> *Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
>
> Hopefully to make it more compatible with existing OAuth 2 libraries.
> At least leave open the possibility of dealing with it
-0300
*To: *Torsten Lodderstedt
*Cc: *Nat Sakimura; OAuth WG
*Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
Hopefully to make it more compatible with existing OAuth 2 libraries.
At least leave open the possibility of dealing with it at a higher
level.
The argument has been made
th-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Phil Hunt
> Sent: Thursday, October 27, 2011 10:49 AM
> To: tors...@lodderstedt.net
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>
> John,
>
> What is the reason behind havin
] On Behalf Of Phil
Hunt
Sent: Thursday, October 27, 2011 10:49 AM
To: tors...@lodderstedt.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering JSON based request.
John,
What is the reason behind having a separate ID_Token from the access Token? I
understand the tokens are used to retrieve d
omitted.
>
> regards,
> Torsten.
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>
> From: John Bradley
> Date: Thu, 27 Oct 2011 13:52:31 -0300
> To: Torsten Lodderstedt
> Cc: Nat Sakimura; OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>
-WG] Rechartering JSON based request.
Hopefully to make it more compatible with existing OAuth 2 libraries.At
least leave open the possibility of dealing with it at a higher level.
The argument has been made that you probably need to modify the library anyway
to check that the duplicate
Hopefully to make it more compatible with existing OAuth 2 libraries.At
least leave open the possibility of dealing with it at a higher level.
The argument has been made that you probably need to modify the library anyway
to check that the duplicate parameters are a match.
If there is conse
Many thanks for pointing this! It is *absolutely* (not "probably")
worth studying.
Igor
On 10/26/2011 6:31 PM, John Bradley wrote:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in
openID Connect to make sign
On 10/26/2011 6:31 PM, John Bradley wrote:
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
why is it neccessary to duplicate the OAuth request parameters?
Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in
openID Connect to make signed requests to the Authoriz
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
It is essentially a standardization of the method we are using in openID
Connect to make signed requests to the Authorization server.
We do have the issue that parameters in the signed/encrypted request
necessarily duplicate the
13 matches
Mail list logo
