Good by me. On Thu, Jan 29, 2015 at 3:35 PM, John Bradley <ve7...@ve7jtb.com> wrote:
> > +--------+ +---------------+ > | |--(A)-- Authorization Request --->| | > | | + t(code_verifier), t | Authorization | > | | | Endpoint | > | |<-(B)---- Authorization Code -----| | > | | +---------------+ > | Client | Authz Server > | | +---------------+ > | |--(C)--- Access Token Request --->| | > | | + code_verifier | Token | > | | | Endpoint | > | |<-(D)------ Access Token ---------| | > +--------+ +---------------+ > > Figure 2: Abstract Protocol Flow > > > > > > Sakimura, et al. Expires August 2, 2015 [Page 4] > > Internet-Draft oauth_pkce January 2015 > > > This specification adds additional parameters to the OAuth 2.0 > Authorization and Access Token Requests, shown in abstract form in > Figure 1. > > A. The client creates and records a secret named the "code_verifier", > and derives a transformed version "t(code_verifier)" (referred to > as the "code_challenge") which is sent in the OAuth 2.0 > Authorization Request, along with the transformation method "t". > B. The Authorization Endpoint responds as usual, but records > "t(code_verifier)" and the transformation method. > C. The client then sends the code in the Access Token Request as > usual, but includes the "code_verifier" secret generated at (A). > D. The authorization server transforms "code_verifier" and compares > it to "t(code_verifier)" from (B). Access is denied if they are > not equal. > > > On Jan 29, 2015, at 7:16 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > Works for me. The text below needs to be fixed up to match too. > > On Thu, Jan 29, 2015 at 3:14 PM, John Bradley <ve7...@ve7jtb.com> wrote: > >> How about >> >> +--------+ +---------------+ >> | |--(A)-- Authorization Request --->| | >> | | + t(code_verifier), t | Authorization | >> | | | Endpoint | >> | |<-(B)- Authorization Code Grant --| | >> | | +---------------+ >> | Client | >> | | +---------------+ >> | |--(C)--- Access Token Request --->| | >> | | + code_verifier | Token | >> | | | Endpoint | >> | |<-(D)------ Access Token ---------| | >> +--------+ +--------------- >> >> >> >> On Jan 29, 2015, at 7:01 PM, Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >> In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization >> request going to the "Resource Owner" and goes on to say that 'the resource >> owner responds as usual, but records "t(code_verifier)" and the >> transformation method.' That's not what the resource owner does. >> >> I know the protocol flow in RFC 6749 tries to have authorization grants >> be these abstract things that sorta come from the resource owner but, in >> the context of the the authorization request and authorization code grant >> type, it really doesn't work like that. The content in §1.1 seems, at best, >> to be more abstract and complicated than it needs to be and is bordering >> on being just kinda wrong. >> >> The RO and AS boxes should probably be consolidated into just the AS. The >> RO could be omitted from the diagram, I think. Or stick it over with the >> client, if you really want it in there, and have it authenticating and >> approving authorization though an interaction with the AS. Or something >> like that... >> >> >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 >> >> 1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>. >> Protocol Flow >> >> +--------+ +---------------+ >> | |--(A)-- Authorization Request --->| | >> | | + t(code_verifier), t | Resource | >> | | | Owner | >> | |<-(B)--- Authorization Grant -----| | >> | | +---------------+ >> | Client | >> | | +---------------+ >> | |--(C)--- Access Token Request --->| | >> | | + code_verifier | Authorization | >> | | | Server | >> | |<-(D)------ Access Token ---------| | >> +--------+ +---------------+ >> >> Figure 2: Abstract Protocol Flow >> >> >> This specification adds additional parameters to the OAuth 2.0 >> Authorization and Access Token Requests, shown in abstract form in >> Figure 1. >> >> A. The client creates and records a secret named the "code_verifier", >> and derives a transformed version "t(code_verifier)" (referred to >> as the "code_challenge") which is sent in the OAuth 2.0 >> Authorization Request, along with the transformation method "t". >> B. The resource owner responds as usual, but records >> "t(code_verifier)" and the transformation method. >> C. The client then sends the code to the Access Token Request as >> usual, but includes the "code_verifier" secret generated at (A). >> D. The authorization server transforms "code_verifier" and compares >> it to "t(code_verifier)" from (B). Access is denied if they are >> not equal. >> >> >> >> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
