Re: [OAUTH-WG] Shepherd report for draft-ietf-oauth-dyn-reg
Thanks for catching the typo. Regarding the IPR (or more copyright) there is an open issue that I was not able to resolve since neither Scott Bradner nor Jorge (the IETF lawyer) responded to me. I updated the write-up! Ciao Hannes On 01/29/2015 12:31 AM, Kathleen Moriarty wrote: Hi Hannes, I am going through the shepherd report for draft-ietf-oauth-dyn-reg and see that this still lists an open question around IPR, has that been answered and is just a matter of updating the shepherd report? If not, how can I help resolve these questions? I also found a nit in #7 that you may want to fix, did should be didn't. The working group did seem to worry about these aspects though. Thanks for the report and your work shepherding the draft. Copying Oauth because of the IPR concern. signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Misplaced Resource Owner in PKCE
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
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
++ +---+ ||--(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 mailto: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 mailto: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 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
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
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
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
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 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. smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
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 | ||
Re: [OAUTH-WG] PKCE: SHA256(WAT?)
FYI, we are now tracking this issue at: https://bitbucket.org/Nat/oauth-spop/issue/32/clean-up-definitions 2015-01-30 8:15 GMT+09:00 Brian Campbell bcampb...@pingidentity.com: In §2 [1] we've got SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of STRING. But, in the little cow town where I come from anyway, you hash bits/octets not character strings (BTW, STRING isn't defined anywhere but it's kind of implied that it's a string of characters). Should it say something more like SHA256(STRING) denotes a SHA2 256bit hash [RFC6234] of the octets of the ASCII [RFC0020] representation of STRING.? I know it's kind of pedantic but I find it kind of confusing because the code_verifier uses the url and filename safe alphabet, which has me second guessing if SHA256(STRING) actually means a hash of the octet produced by base64url decoding the string. Maybe it's just me but, when reading the text, I find the transform process to be much more confusing than I think it needs to be. Removing and clarifying some things will help. I hate to suggest this but maybe an example showing the computation steps on both ends would be helpful? Also UTF8(STRING) and ASCII(STRING) notations are defined in §2 but not used anywhere. And §2 also says, BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Section 3, producing a UTF-8 sequence of octets. But what is a UTF-8 sequence of octets? Isn't it just a sequence octets? The [RFC3629] reference, I think, could be removed. [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-2 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
