and inline again ... :)
On Tue, Jan 16, 2018 at 1:50 PM, Brian Campbell
wrote:
> Inline also...
>
> On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt wrote:
>
>> Comments inline ...
>>
>> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>>
>>> *On client_id:
Inline also...
On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt wrote:
> Comments inline ...
>
> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>>
>> *On client_id:*
>> With the authorization_code code grant (sec
>> https://tools.ietf.org/html/rfc6749#section
Comments inline ...
On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell
wrote:
>
> *On client_id:*
> With the authorization_code code grant (sec https://tools.ietf.org/html/rf
> c6749#section-4.1.3), the client_id is "REQUIRED, if the client is not
> authenticating with the authorization server as d
*On client_id:*
With the authorization_code code grant (sec https://tools.ietf.org/html/
rfc6749#section-4.1.3), the client_id is "REQUIRED, if the client is not
authenticating with the authorization server as described in Section
3.2.1." And Section 3.2.1 (see https://tools.ietf.org/html/
rfc6749
02 version uploaded, and now at
https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/
Hannes: Keeping the same filename while it is an ID as it breaks the
automated process for updating. Will s/mutual/reciprocal/ if adopted and
file name is changed to reflect adoption.
On Tue, Jan 16, 201
Brian
*grant type*
Thanks for the grant type pointers.
*client_id*
The reciprocal flow by its nature is part of a code_grant flow, and I
expect that party A and party B can be reversed. Given that, it is unclear
why client_id would not be required. Would you elaborate?
*response*
Agree a respons
*Attendees*:Dick Hardt, Aaron Parecki, Brian Campbell, Dave Tonge, Eve
Maler, John Bradley, Justin Richer, Nat Sakimura, Samuel Erdtman, Tim,
Cappalli, Denis Pinkas, Bjorn Hjelm, Hannes Tschofenig, and Rifaat
Shekh-Yusef.
Dick presented the attached Mutual OAuth slides, which is the same slides
h
A few thoughts on the new draft and/or reiterating comments from the call
earlier.
"[DH: should this be a URI?]" - yes, the grant type should be a URI
because, for better or worse, that's how OAuth allows for new grants
https://tools.ietf.org/html/rfc6749#section-4.5 (the device flow and JWT
autho
Hi Dick,
maybe you can re-submit the document with a new filename that matches
the updated title.
Ciao
Hannes
On 01/16/2018 03:39 PM, Dick Hardt wrote:
> I have made changes based on feedback on the call this morning. Updated
> version at:
___
OAuth
I have made changes based on feedback on the call this morning. Updated
version at:
https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/
/Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
10 matches
Mail list logo