Re: [OAUTH-WG] Token Chaining Use Case
The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases, and it’s still not OAuth-y at all. It requires a specially-formed security assertion on the way in, which the client must understand and generate. I still can’t take an arbitrary token I’ve been handed by someone
Re: [OAUTH-WG] Token Chaining Use Case
Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases, and it’s still not OAuth-y at all. It requires a specially-formed security assertion on the way in, which the client must understand and generate. I still can’t take an arbitrary token I’ve been handed by someone else and pass it off to be pushed forward. The new “*_type” parameters seem to merely kick the can down the road instead of addressing the problems with the current specification. I think that Brian’s approach works much better. It unrolls important parameters, properly uses the token endpoint, and allows for arbitrarily formatted input tokens. When combined with Nat’s draft that specifies how to perform all generic OAuth requests as JWTs (or even some of the upcoming PoP work if we ever do that), you’ve pretty much got the draft below but with much more flexibility and power. — Justin On Jul 7, 2015, at 6:51 PM, Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com wrote: As just updated http://self-issued.info/?p=1412, I believe that the working group token exchange draft https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02 can now also serve the “OAuthy” token exchange use cases, such as Justin and Phil’s token chaining use case, as well as support general token exchange, including exchange of JWT and SAML tokens. The mechanism would be the same one that Brian suggested below – defining security token type values for OAuth 2.0 access tokens and refresh tokens – enabling them to
Re: [OAUTH-WG] Token Chaining Use Case
There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones michael.jo...@microsoft.com wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:* Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases, and it’s still not OAuth-y at all. It requires a specially-formed security assertion on the way in, which the client must understand and generate. I still can’t take an arbitrary token I’ve been handed
Re: [OAUTH-WG] Token Chaining Use Case
Hi all. After reading Brian’s note, he and I spoke on the phone to try to clear a few things up and work on a collaborative path forward. Here’s some of what we talked about… First, I’m sorry that I may have contributed to the impression that there’s little willingness on my part to consider changes to the draft. That’s not the case and the truth is actually much simpler than that… I’d been super-busy doing other things, including finishing JWT, JOSE, OAuth Assertions, helping develop and launch the OpenID Certification programhttp://openid.net/certification/, and several other valuable things, and I simply hadn’t given token exchange any significant bandwidth for a while as a result. Now that many of those things are done, I do have bandwidth to work on it now. One concrete thing Brian and I agreed to do as a next step is to work on a list of issues and choices for the working group to consider together, which we’ll jointly present in Prague. Hopefully that will help reduce some of the confusion and replace it with a clear an actionable engineering analysis of the options available to us. I know we both share the goal of keeping things as simple and efficient as possible, while enabling support for the token exchange use cases that different applications actually need. One other thing that we both think would help people better understand and use the resulting spec is to have a number of clear, illustrative examples. Face it, whatever you call it (delegation, impersonation, on-behalf-of, act-as, etc.), some of the concepts are subtle, and so the more we can shed light on them through concrete examples, the easier I suspect that we can make it for people to both understand what they are and how they apply to their use cases. I’m looking forward to seeing many of you in Prague pretty soon! -- Mike From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Wednesday, July 08, 2015 12:33 PM To: Mike Jones Cc: Justin Richer; oauth@ietf.org Subject: Re: [OAUTH-WG] Token Chaining Use Case There is a lot in common, yes. Fundamentally we're working to address the same needs, which should lead to some commonality. But I was also trying to be conciliatory in the work I did and make a good faith effort at establishing some commonality from which collaborative work could move forward. In retrospect I should probably have just outright opposed the adoption of draft-jones-oauth-token-exchange as a WG item. I thought trying to work with you would be more effective than working against you. At the time you seemed amenable to that and even proposed co-editing with. Hannes followed that indicating support for adding other co-authors (he didn't say it but kind of implied perhaps Justin and/or Phil based on prior related work). Since that time, however, there's been little willingness to consider changes to the draft (other than very trivial items). And Tony was added as a co-author, which to me (and I suspect many others) signals a complete lack of willingness to actually collaborate towards a solution that's acceptable to more than one contingent. There are differences in the drafts too. I won't list them all here but did want to call out that, contrary to what you said, the request in my draft is made up of regular old HTTP form-urlencoded POST parameters. Which is a simplification and efficiently improvement that seems to be preferred. On Tue, Jul 7, 2015 at 6:41 PM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request *is* the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to
Re: [OAUTH-WG] Token Chaining Use Case
Agree Sergey. That line of thinking is largely why https://tools.ietf.org/html/draft-campbell-oauth-sts utilizes normal OAuth client authentication. On Wed, Jul 8, 2015 at 3:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 08/07/15 01:41, Mike Jones wrote: [...] That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token Chaining Use Case
We seem to be developing request signing for the RS as part of POP, signed requests for the Authorization endpoint, and a option of wrapping everything in a JWT for the token endpoint. The Authorization endpoint being accessed via a redirect is one case, and the others are for direct access. In other things I have been tempted to just wrap everything inside the JWT, but that is perhaps not a good example of how to build a REST API. Perhaps looking at the POP idea in Justin's draft of sending a detached signature in a JWT is something that could be generalized for direct communications beyond the RS. We probably want a strategy on how we want to deal with signed requests across the various endpoints and with an eye to the upcoming token binding specs where appropriate. I think everyone agrees that we need some token in token out functionality that supports impersonation and composite output tokens and can work with both bearer and pop types of output tokens. We also seem to have some differing ideas. It is up to us to pull those together. John B. On Jul 8, 2015, at 8:40 AM, Justin Richer jric...@mit.edu wrote: The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a
Re: [OAUTH-WG] Token Chaining Use Case
Probably goes without saying but I'm generally in agreement with Justin here. On Wed, Jul 8, 2015 at 5:40 AM, Justin Richer jric...@mit.edu wrote: The HTTP *request* should be able to be covered by a JWT signature, and that should be applicable to any interaction with the token endpoint. I’m aware that Nat’s draft is talking about the authorization endpoint, but the same logic could be applied here at the token endpoint. It could actually even be easier there because we could simply specify that the Content-Type of the input POST is application/jwt and the payload of said JWT simply contains all the parameters to the token endpoint. Orthogonal functionality that meshes well together. Brian’s draft puts everything as a parameter, including the input token (which can be arbitrary — the requester doesn’t need to know what’s in the tokens at all). This could easily be turned wholesale into an input JWT using the transform just described. The current draft is a weird halfway state where some input parameters are in a JWT that’s passed as an input parameter alongside other things that are outside the JWT. I don’t think that works particularly well, and I think there’s a better, simpler solution that solves all of these use cases and then some. — Justin On Jul 8, 2015, at 5:26 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi, On 08/07/15 01:41, Mike Jones wrote: I’ll start by saying that if you compare https://tools.ietf.org/html/draft-campbell-oauth-sts-02 and https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-02, unsurprisingly, you’ll find a lot in common. Both have requests and responses formatted using JSON objects, both have input and output tokens, both have security token type parameters describing their corresponding inputs and outputs. Both can convey act_as and on_behalf_of tokens. And despite what was written below, both define a new grant_type value that is used to make this new kind of request at the Token Endpoint. The primary thing that Brian’s draft is missing semantically is the ability for the requester to sign the set of input parameters. This is critical to establishing proper trust to enable the exchange to occur in many use cases. That’s why the WG draft uses a JWT as the request – so a signature can be applied to the request, when appropriate. (And when it’s not needed, “alg”: “none” can be used.) The requester is a client talking to the token endpoint and this client needs to authenticate, why it needs to sign the token-exchange related parts too ? Thanks, Sergey Justin, you’re right that the current WG draft doesn’t have a separate “input token” request parameter. In the current draft, the (optionally) signed request **is** the input token. Thinking some more about the token chaining use case you’re interested in, I see why you want to have that token to be a separate element in the request. I believe the best way to accomplish that is to add an optional claim to the request that would contain that token. (I think the closest equivalent in Brian’s draft is the possibility of using an access token or assertion as the client authentication mechanism, possibly passing it as defined in RFC 6750, although the draft doesn’t say that.) Passing the input token as a claim lets it be part of the signed request. It’s completely up to us when using a different grant_type to define what the input and output parameters when using that grant_type are. (RFC 6749 already has different sets, depending upon the grant_type used.) I personally find it cleaner to return the output security token that may not be an access token in a “security_token” parameter rather than repurposing the “access_token” parameter to hold something that’s not an access token, but now we’re more discussing syntax than semantics. Still, if something is different, it’s probably less error prone to use a different syntax for it. I’m sympathetic to your comment about Nat’s signed requests draft, except that the requests that draft specifies are requests to the interactive Authorization Endpoint, whereas the requests we’re dealing with here are requests to the non-interactive Token Endpoint. Still, thinking of the Token Exchange requests as signed requests to the Token Endpoint, just like Nat’s draft makes signed requests to the Authorization Endpoint, is probably a good unifying mental framework for all of us to consider applying to this problem space. Best wishes, -- Mike *From:*Justin Richer [mailto:jric...@mit.edu] *Sent:* Tuesday, July 07, 2015 4:47 PM *To:* Mike Jones *Cc:* Brian Campbell; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Token Chaining Use Case This approach is not a good fit for my use cases, and
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt
Following up the discussion on today's NAPPS call, I understand why plain is not presented as the recommended approach in the spec (though it still has some value over not doing PKCE at all, in that it mitigates against the current known attack where a rogue app registers the same custom URI scheme as another), but I feel that after all the back and forth the picture is a little confusing. In particular, 4.2 and 4.4.1 include some examples where plain is supported: 4.2 Clients SHOULD use the S256 transformation. The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation. 4.4.1. If the client is capable of using S256, it MUST use S256, as S256 is Mandatory To Implement (MTI) on the server. Clients are permitted to use plain only if they cannot support S256 for some technical reason and knows that the server supports plain. But then 7.2 is very vocal that it MUST NOT be used for new implementations: 7.2 Because of this, plain SHOULD NOT be used, and exists only for compatibility with deployed implementations where the request path is already protected. The plain method MUST NOT be used in new implementations. What if those new implementations are constrained, as indicated in 4.2 and 4.4.1? Also, while S256 is clearly indicated as MTI, little is said about plain, although it's alluded to that it's not MTI in 4.4.1 (and knows that the server supports plain). Should we be more explicit upfront that plain is optional for servers to support, if that's the intention? On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wdenn...@google.com wrote: t_m works for me, I just think we should have some indication that it's the name of the transform. Will you also update where it is referenced in the description below Figure 2? On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote: Thanks, I fixed my finger dyslexia for the next draft. I changed it to t_m rather than “t” I think that is clearer. If I were to do it the other way XML2RFC would have double quotes in the text version. John B. On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote: In version 14, there's a typo on this line (deso) in Section 7.2: `plain method deso not protect` Also, in the 1.1 Protocol Flow diagram, regarding the text: `+ t(code_verifier), t` I wonder if it makes more sense to represent as `+ t(code_verifier), t` (note the quotes on the second 't') given that it's a string representation of the method that's being sent? On Mon, Jul 6, 2015 at 4:05 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof Key for Code Exchange by OAuth Public Clients Authors : Nat Sakimura John Bradley Naveen Agarwal Filename: draft-ietf-oauth-spop-14.txt Pages : 20 Date: 2015-07-06 Abstract: OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced pixy). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-spop-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
