Re: [OAUTH-WG] Review draft-ietf-oauth-spop-00
Hi Eduardo, I have accepted all the Suggestions in the forthcoming version. You can see my private editing copy at https://bitbucket.org/Nat/oauth-spop/commits/f0f8599 to see how it has been incorporated. Best, Nat On Wed, 03 Sep 2014 01:57:31 -0600 Eduardo Gueiros eguei...@jive.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Review of draft-ietf-oauth-spop-00 Gentleman, here are some notes on the OAuth SPOP Draft. Review Summary A few grammar errors, no major flaws, some suggestions that could possibly make some passages clearer. Some questions as well. Also, providing a flow diagram would help clarify some of the interactions. Abstract The OAuth 2.0 public client utilizing authorization code grant is susceptible to the code interception attack. Suggestion for clearer reading: OAuth 2.0 public clients utilizing Authorization Code Grant (RFC 6749 - - 4.1) are susceptible to an interception attack. Introduction Suggestion for clearer reading: Public clients in OAuth 2.0 [RFC6749] is susceptible to the code interception attack. The code interception attack is an attack that a malicious client intercepts the code returned from the authorization endpoint and uses it to obtain the access token. Public clients utilizing OAuth 2.0 are susceptible to authorization code interception attack. A malicious client intercepts the authorization code returned from the authorization endpoint and uses it to obtain the access token. Suggestion for clearer reading: This is especially true on some smartphone platform in which the code is returned to a redirect URI with a custom scheme as there can be multiple apps that can register the same scheme. This is especially true on smartphones applications where the authorization code can be returned through custom URL Schemes where the same scheme can be registered by multiple applications. Insert article before ‘dynamic’ To mitigate this attack, this extension utilizes dynamically created cryptographically random key called 'code verifier'. To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called 'code verifier'. Missing commas for context The code verifier is created for every authorization request and its transformed value called code challenge is sent to the authorization server to obtain the authorization code. The code verifier is created for every authorization request and its transformed value, called code challenge, is sent to the authorization server to obtain the authorization code. 2 Terminology 2.1 Question Random String: What constitutes ‘big enough entropy’? Shouldn’t minimum length be specified (e.g. 32 characters)? 3 Protocol 3.1 Question This paragraph states that the client must, through some mechanism, verify if the server supports this specification. Shouldn’t this mechanism be part of OAuth and therefore have an specification document on how to implement and perform the aforementioned verification? Suggestion: Change MUST to SHOULD The client that wishes to use this specification MUST stop proceeding if the server does not support this extension. I think a client can use this mechanism to implement a more secure transaction, but by verifying it, the client can be configured to continue performing the regular authorization grant if it chooses so. Hence, SHOULD instead of MUST. 3.3 Question Goes with question on 2.1, why less than 128 bytes? Suggestion string of length less than 128 bytes string of length no less than 128 bytes Eduardo Gueiros Software Developer | Jive.com Jive Communications, Inc | egueiros at jive.com -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJUBsnrAAoJEInLDRowktwYn6sH+wUGGCimGSRaSfy4LeN9ug9e VN5R/N4eWhEKl5iydMZskeMovYsH4PhEP19m56mWGhRn53CxMB5dlHkTw56JX4mS qnPu96Ot6HoCzzCVj8PtGyAZUwWFyd57Ff7uUuSQaVghhIfLXzggFfciiErJpV5H wwQo+eFp98fx6uGEeCr4Olr6PsJ8Ajn5SnaCA/dPr7YWAUrnpSb55NCB4twtp4y6 36EqjcuvafudTEuYJOoGqYJppfpcZ+Da6uKZNRTahkN1ivv1C+PdNRWkfHbB47mu IF4u3b6tDhiymPNFjCABZ6gB5ZbXmUbVrkhVKwJpf/87/fiaScGmZG+6rRZLP5s= =XQSw -END PGP SIGNATURE- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (n-sakim...@nri.co.jp) Nomura Research Institute, Ltd. 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 することを意図しております。意図された受取人以外の方によるこれらの情報の 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 信されたメールを削除していただきますようお願い致します。 PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or
[OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review)
In his mail, Hannes suggested to include more explicit reference to a feature in the OpenID Connect Discovery spec in section 3.1. My response to it was that we could define a parameter here and ask the implementers to implement it. Questions remains whether we want to define it here or leave it to be out of scope. So, my questions are: (1) Do we want it? (y or n) (2) if y, then adding the following text at the end of 3.1 be adequate? When the server supports OpenID Connect Discovery 1.0, the server MUST advertise its capability with a parameter spanx style=verboauth_spop_supported_alg/spanx. The value of it is a JSON array of JSON strings representing alg (Algorithm) Header Parameter Values for JWS as defined in xref target=JWAJSON Web Algorithms/xref. Nat On Wed, 3 Sep 2014 02:28:57 +0900 Nat Sakimura sakim...@gmail.com wrote: Hi. Thanks for the detailed comments. Here are the responses to the questions raised in [1] [1] http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc 3.1 [Question: Would it make sense to provide some information also in the Dynamic Client Registration specification? I am a bit unhappy about not specifying at least one mechanism for learning this information since it is important for the overall security -- to avoid downgrading attacks.] I would have included it if OAuth has defined a discovery document. n fact, it may be a good starting point to discuss whether we should have a discovery document for OAuth. If the client does the per client registration, then it will not be a public client so spop would not be needed. The clients as a class may register itself, but then each client instance would not know if the server knows that it is using spop, and assuming it without verifying is not very safe. 3.1 [Hannes: Can we make a more explicit reference to a feature in the OpenID Connect Discovery specification?] It will be an extension to section 3 of OpenID Connect Discovery. This specification may define a JSON name for such a parameter. Then, one can include it in the metadata. A candidate for such name would be: oauth_spop_supported_alg: and the value would be the strings representing supported algorithms. It could be drawn from JWA algs. A simpler alternative would be: oauth_spop_support: and the value would be true or false. However, we have no good place to advertise them as of now. 3.2 [Hannes: Do we really need this flexibility here?] It is there as an extension point. John has a draft that uses aymmetric algo. An early draft had HMAC as well. We could however drop it. I suppose we can add other algorithms later without breaking this one. [Hannes: The term 'front channel' is not defined anywhere.] Will define if this section survives. 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] The server may have other considerations before returning successful response. 5. [Hannes: Which request channel are you talking about? There are two types of request channels here, namely the Access Token Request/Response and the Authorization Request / Response channel. What do you mean by adequately protected here? How likely is it that this can be accomplished? If it is rather unlikely then it would be better to define a different transformation algorithm!] This is referring to the authorization request. On iOS as of the time of writing, not Jailbreaking seems to be adequate. For Android, only presenting the intended browser as the options to handle the request seems adequate. Similar considerations would be there per platform. Note: Authors do think that using other algorithms is better. However, it proved to be rather unpopular among the developers that they were in touch with and believe that we do need to provide this no-transform capability. For other corrections, I am still working on to prepare comments as word comments. Most of editorial changes will be accepted. Some proposed technical changes seems to be due to the clauses being unclear, so I will try to propose a clarification rather than just accepting them. Best, Nat 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig hannes.tschofe...@gmx.net: Hi John, Hi Nat, I went through the document in detail and suggest some changes (most of them editorial): http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf My main concern at the moment are some optional features in the spec that make it less interoperable, such as the feature discovery, and the transformation function. The latter might go away depending on your answer to my question raised at http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html but the former requires some specification work. Ciao Hannes PS: I agree with James that the title of the document is a bit
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Hi Phil, All, Thanks for your positive feedback and further comments below. My goal was really about trying to make a clear picture in my mind about what OIDC is with respect to OAuth2, and specifically supporting the point about OIDC not being just OAuth2. As such, the idea of a specific OIDC profile where no access token was used appealed to me but really in light of supporting the same point that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC OAuth2-based model. Hence I also tried to suggest that even though OIDC does return an access token, this token does not have to be a full-powered token that a client can use to access something else but a user profile endpoint (unless custom scopes are also used). So the access token is there but it's only usable in the OAuth2 world. I respect the effort done in the a4c draft - I'm just not sure really it has to be a separate effort (as opposed to it being an OIDC 'exception' light weight profile - can be simpler for users like me to have it all comprehended when it is a single family of docs) should the experts like yourself and others really like the idea of having a pure authentication flow supported. But I'll be watching with the interest how it all evolves now :-) Thanks, Sergey On 13/10/14 22:17, Phil Hunt wrote: Sergey, Actually, I think your comments are fine. They add to the discussion on why A4C is distinct from OIDC’s larger IDP role in an OAuth style flow and why *both* are needed. Comments in line. Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Phil Thanks for the clarifications, On 13/10/14 20:18, Phil Hunt wrote: The point to be made is if the client’s objective is to authenticate the User, the base 6749 spec does not guarantee this at all. It simply authorizes the client to access a resource and nothing more. It turns out that a significant part of the time authentication does occur, but the client does not have access to that information. Nor can it specifically request re-authentication. Further, if the client doesn’t wield the access token, its might not be proof that the token received was actually an authorization. OpenID gives you both authen information and authorization profile information (as a resource). Yes, I experimented with it. This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when. While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree. Sure. It an authentication flow and should be distinct IMHO. I guess that is why the idea of having an OIDC profile dedicated to the authentication alone (no access token) which I believe was suggested here caught my attention. But then it is not OAuth2 and hence not OIDC. The chicken in the egg situation :-). As I said in the prev email, having an access token which is really restricted to the OIDC resource (profile) seems like a good compromise… [PH] We discussed this in Toronto and OIDC can’t do this and be compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out that the OAuth WG isn’t chartered to do authentication and that kind of killed the discussion leaving the issue hanging unresolved. If you look at draft 00 of the A4C draft you will note that I originally proposed it as a new end-point. My feeling it should NOT be an OAuth flow - because as Justin says, if you aren’t returning an access token, you aren’t doing OAuth. The issue is that the technical redirect flow for authentication and authorization share the same security risks and counter-measures. It would be good therefore to build “in-parallel” or “underneath” OAuth to define an authn flow. I would still recommend OIDC as a layer on top of OAuth that defines the standard way to get profile claims (the full OAuth style IDP functionality). That said, I am in the minority with this opinion and I acknowledge as being as such. Sorry if I hijacked this thread and started the off-topic 'flow'...I guess my reasoning here is a bit all over the place, but I'm pretty sure now I see the big picture better Thanks, Sergey Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 13/10/14 15:17, Justin Richer wrote: You certainly can do authentication without using an access token, but then I would argue that's no longer OAuth. Basically you're making tofu carob fudge. Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the info in the id_token is sufficient ? I guess as far as a typical OAuth2 client is
[OAUTH-WG] SPOP - code verifier requirements
In his mail, Mike asked whether code verifier is a value that is sendable without trnasformation as a http parameter value, or if it needs to be % encoded when it is being sent. We have several options here: 1) Require that the code verifier to be a base64url encoded string of a binary random value. 2) Let code verifier to be a binary string and require it to be either % encoded or base64url encoded when it is sent. In this case, which encoding should we use? 3) require the code verifier to be conform to the following ABNF: code_verifier = 16*128unreserved unreserved= ALPHA / DIGIT / - / . / _ / ~ Which one do you guys prefer? Nat -- Nat Sakimura (n-sakim...@nri.co.jp) Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt
Sorry for the noise, On 14/10/14 10:25, Sergey Beryozkin wrote: Hi Phil, All, Thanks for your positive feedback and further comments below. My goal was really about trying to make a clear picture in my mind about what OIDC is with respect to OAuth2, and specifically supporting the point about OIDC not being just OAuth2. As such, the idea of a specific OIDC profile where no access token was used appealed to me but really in light of supporting the same point that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC OAuth2-based model. Hence I also tried to suggest that even though OIDC does return an access token, this token does not have to be a full-powered token that a client can use to access something else but a user profile endpoint (unless custom scopes are also used). So the access token is there but it's only usable in the OAuth2 world. meant to say in the OIDC world and as such it is a limited token I respect the effort done in the a4c draft - I'm just not sure really it has to be a separate effort (as opposed to it being an OIDC 'exception' light weight profile - can be simpler for users like me to have it all comprehended when it is a single family of docs) should the experts like yourself and others really like the idea of having a pure authentication flow supported. But I'll be watching with the interest how it all evolves now :-) Thanks, Sergey On 13/10/14 22:17, Phil Hunt wrote: Sergey, Actually, I think your comments are fine. They add to the discussion on why A4C is distinct from OIDC’s larger IDP role in an OAuth style flow and why *both* are needed. Comments in line. Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Phil Thanks for the clarifications, On 13/10/14 20:18, Phil Hunt wrote: The point to be made is if the client’s objective is to authenticate the User, the base 6749 spec does not guarantee this at all. It simply authorizes the client to access a resource and nothing more. It turns out that a significant part of the time authentication does occur, but the client does not have access to that information. Nor can it specifically request re-authentication. Further, if the client doesn’t wield the access token, its might not be proof that the token received was actually an authorization. OpenID gives you both authen information and authorization profile information (as a resource). Yes, I experimented with it. This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when. While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree. Sure. It an authentication flow and should be distinct IMHO. I guess that is why the idea of having an OIDC profile dedicated to the authentication alone (no access token) which I believe was suggested here caught my attention. But then it is not OAuth2 and hence not OIDC. The chicken in the egg situation :-). As I said in the prev email, having an access token which is really restricted to the OIDC resource (profile) seems like a good compromise… [PH] We discussed this in Toronto and OIDC can’t do this and be compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out that the OAuth WG isn’t chartered to do authentication and that kind of killed the discussion leaving the issue hanging unresolved. If you look at draft 00 of the A4C draft you will note that I originally proposed it as a new end-point. My feeling it should NOT be an OAuth flow - because as Justin says, if you aren’t returning an access token, you aren’t doing OAuth. The issue is that the technical redirect flow for authentication and authorization share the same security risks and counter-measures. It would be good therefore to build “in-parallel” or “underneath” OAuth to define an authn flow. I would still recommend OIDC as a layer on top of OAuth that defines the standard way to get profile claims (the full OAuth style IDP functionality). That said, I am in the minority with this opinion and I acknowledge as being as such. Sorry if I hijacked this thread and started the off-topic 'flow'...I guess my reasoning here is a bit all over the place, but I'm pretty sure now I see the big picture better Thanks, Sergey Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 13/10/14 15:17, Justin Richer wrote: You certainly can do authentication without using an access token, but then I would argue that's no longer OAuth. Basically you're making tofu carob fudge. Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the
Re: [OAUTH-WG] Blackhat US: OAuth Talk
hi Hannes, thanks for the link. It is interesting. Said that I think the attack shown there are a bit “academic” and do not reflect the real life situation. Moreover it still mention the MAC flow when AFAIK the OAuth working group decided to deviate from it. IMHO the majority of real life attacks (and I can provide many many examples taken from blog posts of people that hacked big providers such Google,Facebook, Github etc) are actually targeting two things: - weak/incorrect validation of the redirect_uri parameter - leak of the access token . authorization code from the referrer just my 0.02 cents :) regards antonio On Oct 13, 2014, at 6:35 PM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: During the OAuth conference call today I asked whether someone had looked at this paper published at the recent Blackhat US conference and nobody knew about it. Hence, I am posting it here: * Paper: https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week-WP.pdf * Slides: https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week.pdf Ciao Hannes ___ 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-WG] I-D Action: draft-ietf-oauth-json-web-token-28.txt
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 : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename: draft-ietf-oauth-json-web-token-28.txt Pages : 34 Date: 2014-10-14 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-28 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-WG] FW: JOSE -34 and JWT -28 drafts addressing IESG review comments
From: Mike Jones Sent: Tuesday, October 14, 2014 5:39 AM To: j...@ietf.org Subject: JOSE -34 and JWT -28 drafts addressing IESG review comments Updated JOSE and JWT specifications have been published that address the IESG review comments received. The one set of normative changes was to change the implementation requirements for RSAES-PKCS1-V1_5 from Required to Recommended- and for RSA-OAEP from Optional to Recommended+. Thanks to Richard Barnes, Alissa Cooper, Stephen Farrell, Brian Haberman, Ted Lemon, Barry Leiba, and Pete Resnick for their IESG review comments, plus thanks to Scott Brim and Russ Housley for additional Gen-ART review comments, and thanks to the working group members who helped respond to them. Many valuable clarifications resulted from your thorough reviews. The specifications are available at: *http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-34 *http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-34 *http://tools.ietf.org/html/draft-ietf-jose-json-web-key-34 *http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34 *http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-28 HTML formatted versions are available at: *http://self-issued.info/docs/draft-ietf-jose-json-web-signature-34.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-34.html *http://self-issued.info/docs/draft-ietf-jose-json-web-key-34.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-34.html *http://self-issued.info/docs/draft-ietf-oauth-json-web-token-28.html -- Mike P.S. I also published this note at http://self-issued.info/?p=1291 and as @selfissued. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS)
These resolutions have been incorporated in the -28 draft. Thanks again for your review. -- Mike From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Thursday, October 02, 2014 8:21 AM To: Mike Jones Cc: Alissa Cooper; The IESG; oauth-cha...@tools.ietf.orgmailto:oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.orgmailto:draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) On Thu, Oct 2, 2014 at 11:14 AM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: Responding to the DISCUSS below… -Original Message- From: Alissa Cooper [mailto:ali...@cooperw.inmailto:ali...@cooperw.in] Sent: Wednesday, October 01, 2014 12:25 PM To: The IESG Cc: oauth-cha...@tools.ietf.orgmailto:oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.orgmailto:draft-ietf-oauth-json-web-to...@tools.ietf.org Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Alissa Cooper has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- == Section 12 == A JWT may contain privacy-sensitive information. When this is the case, measures must be taken to prevent disclosure of this information to unintended parties. It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well. There seems to be debate whether a 2119 language should be used other than when describing protocol requirements. Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention. With other documents, there is RFC2119 language used for security privacy considerations. At some point there was a trend to have a separate Security Requirements section from Security Considerations, but I don't think there was any requirement for this, just a preference. I agree that this should be a MUST, but with Stephen as well that you should discourage putting in privacy related information to begin with. One way to achieve this is to use an encrypted JWT. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols, such as TLS. Since sensitive JWTs should be protected from both intermediary observation and from being sent to unintended recipients, I would suggest: One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS. Thanks for this suggested language. We can incorporate something like that. OK, this makes sense and will feed into Pete's discuss on where TLS should be required. Thanks! -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
The proposed resolutions have been applied to the -28 draft. Hopefully this will enable to clear your DISCUSSes. Thanks again for the careful read! -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Saturday, October 04, 2014 5:17 PM To: Barry Leiba; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web- token-27: (with DISCUSS and COMMENT) Thanks for your review, Barry. I'm adding the working group so they’re aware of these comments. At Stephen Farrell's request, I'm responding with line prefixes on previous thread content. I'm also repeating (and in the first case, augmenting) my previous responses to the DISCUSS comments in this consolidated message. -Original Message- From: Barry Leiba [mailto:barryle...@computer.org] Sent: Wednesday, October 01, 2014 8:54 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Barry Leiba has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- I have two points that I'd like to get resolved before happily approving this fine document: -- Section 7.1 -- The comparison you specify is as specified in RFC 7159, Section 8.3, which is to transform the textual representation into sequences of Unicode code units and then perform the comparison numerically, code unit by code unit. This has no regard for text case, and so it's a case-sensitive comparison. And, yet, Sections 5.1 and 5.2 specify that the values of typ and cty are case- insensitive, and specify using upper case as a SHOULD, for compatibility with legacy implementations. It doesn't seem that legacy has anything to do with this: someone conforming to *this* specification will compare the values of typ and cty Unicode-character by Unicode-character, and will fail to match JWT with jwt. Is there not a problem here? We can update the text to clarify that MIME type comparisons are an exception to the “code unit by code unit” comparison rule. The drafts will also be scrutinized for other possible occurrences of exceptions to the default string comparison instructions. Finally, we can add language to 7.1 about unless otherwise noted for a particular kind of string so that it's clear that there are exceptions to the rule. -- Section 10.3.1 -- Nice that you cite 2046 for media types, but the *registration* of media types is documented in RFC 6838, and this document doesn't quite conform to that. The only thing missing in the doc is Fragment identifier considerations in the registration template, but 6838 also strongly suggests review of the media-type registration on the media-types mailing list. Given that this will not get expert review (because it's an IETF-stream RFC), I'd like to ask for an explicit review on the media-types list to make sure that the registration information is complete and makes sense. Thanks for the 6833 reference. We’ll use that. I know that Kathleen already initiated the review on the media-types list. -- COMMENT: -- -- Abstract -- The suggested pronunciation of JWT is the same as the English word jot. I have no objection (well, I do, but it's not for me to say how you want to pronounce it) to having this sentence in the Introduction, but it seems out of place in the Abstract, which is meant to be concise. OK - We can remove it from the Abstract. -- Section 4.1 -- It appears that all claims defined here are OPTIONAL, and each one says so in its subsection. Given that they *all* are, it might be useful to say that up front, maybe with a sentence that says, All claims defined in this section are OPTIONAL to use. (I don't feel strongly about this; it's just a suggestion, so do with it as you see best.) See also my comment on 10.1.1, below.
Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
The proposed resolutions below have been included in the -28 draft. Hopefully you'll be able to clear your DISCUSSes on that basis. The String Comparison Rules in Section 7.3 have been expanded to talk about when the application may need canonicalization rules. Thanks again, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Monday, October 06, 2014 7:20 PM To: Stephen Farrell; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json- web-token-27: (with DISCUSS and COMMENT) Thanks for tracking all of this Stephen. Responses inline below... -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Monday, October 06, 2014 2:43 PM To: Mike Jones; The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org; oauth@ietf.org Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Hi Mike, On 06/10/14 08:54, Mike Jones wrote: Thanks for your review, Stephen. I've added the working group to the thread so they're aware of your comments. -Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Sent: Thursday, October 02, 2014 5:03 AM To: The IESG Cc: oauth-cha...@tools.ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Stephen Farrell has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ --- -- - DISCUSS: --- -- - (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS names for another JOSE spec - do you need to say those SHOULD be [upper|lower]cased when used in these? I believe that somewhere we should say that if case-insensitive values, such as DNS names, are used when constructing kid values, that the application doing so needs to define a convention on the canonical case to use for the case-insensitive portions, such as lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end result. Thanks (2) Section 8: Why is none MTI? That seems both broken and going in the oppostite direction from other WGs and so should be explicitly jusified I think. (If a good enough justification exists that is.) It is MTI because there are several existing applications of JWTs in which both unsigned and signed representations of the JWTs are requirements. These include draft-ietf-oauth-token-exchange, draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty common pattern where you sign something if the recipient cares who made the statements and where you don't have to sign it either if the recipient doesn't care who made the statements I don't see how (non-)signers can divine non-verifier's wishes that way. (Absent negotiation or a directory.) Sometimes it does occur via negotiation. For instance, in some protocols, at registration time, relying parties explicitly tell identity providers what algorithms are acceptable to them, which may include none. No divination - explicit communication. or if it can tell from another secured aspect of the application protocol (typically through the use of TLS) who made the statements. In the TLS case, the server authentication step makes a signature step unnecessary, so an Unsecured JWT is fine there. That's arguable IMO. I agree that it's application and context-dependent whether it's OK or not. The point is that there exist some circumstances in which it is OK, and this feature is being used in some of those cases. I think I'll look back over the wg thread and either hold my nose or This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36. Karen O'Donoghue recorded this conclusion in the tracker Note: There was extensive discussion on the mailing list, and the rough consensus of the
Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
The proposed resolution below has been incorporated in the -28 draft. Hopefully you can clear your DISCUSS on that basis. Thanks again, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Saturday, October 11, 2014 12:54 PM To: Richard Barnes Cc: draft-ietf-oauth-json-web-to...@tools.ietf.org; oauth- cha...@tools.ietf.org; The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- token-27: (with DISCUSS and COMMENT) From: Richard Barnes [mailto:r...@ipv.sx] Sent: Friday, October 10, 2014 2:37 PM To: Mike Jones Cc: The IESG; oauth-cha...@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web-to...@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones michael.jo...@microsoft.com wrote: Thanks for your review, Richard. My responses are inline below... -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, October 01, 2014 7:57 PM To: The IESG Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web- to...@tools.ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- token-27: (with DISCUSS and COMMENT) Richard Barnes has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ -- DISCUSS: -- Section 7. In order to prevent confusion between secured and Unsecured JWTs, the validation steps here need to call for the application to specify which is required. Per my response on your JWS comments, this is already handed in a more general way in the JWS validation steps. Specifically, the last paragraph of Section 5.2 is: Finally, note that it is an application decision which algorithms are acceptable in a given context. Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject the JWS. I've cleared this DISCUSS in the interest of having this fight over in JWS thread. But I also added the following COMMENT: It would be good for this document to pass on the note from JWS about selecting which algorithms are acceptable, and in particular, whether unsecured JWTs are acceptable. Thanks for clearing the DISCUSS. I'm fine repeating the note about acceptable algorithms in the JWT spec, assuming others are. I would therefore request that you likewise withdraw this DISCUSS on that basis. -- Mike ___ 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
Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT)
On Oct 14, 2014, at 7:53 AM, Mike Jones michael.jo...@microsoft.com wrote: The proposed resolution below has been applied to the -28 draft. Thanks! ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
I agree with Phil on this one (hey, it happens!): this is a classic example of having one piece of software and many instances of it talking to many different service providers. Each of those pairings is going to need to agree on a client ID, and one would hope a client secret or equivalent. It's not feasible to pre-pack these even with a single authorization service (and Google and MS are setting a bad example here), let alone every server ever. Classical OAuth has a strong relationship between the client developer and the protected resource provider, but this relationship starts to dissolve when you're talking about common APIs. OpenID Connect is one such common API that we're seeing in the web space (and SCIM will likely be another), but the SASL work is going to open up a whole slew of common protected APIs that could use OAuth. As such, dynamic registration is going to be essential for this to be interoperable and scale beyond a single provider / consumer-app pair, and it makes perfect sense for Kitten to adopt it here. -- Justin On Oct 12, 2014, at 8:37 PM, Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com wrote: Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the *classic* use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server implementation and are meant to work with any server. This means that having a pre-negotiated client_id is pretty much impossible without dyn reg or some equivalent solution — and why do another? There may be simpler profiles you can develop specific to SASL, but I think OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.comhttp://www.independentid.com/ phil.h...@oracle.commailto:phil.h...@oracle.com On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net wrote: Hi all, there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well. kind regards, Torsten. Original-Nachricht Betreff:Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt Datum: Sat, 11 Oct 2014 13:30:48 +0200 Von:Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net An: kit...@ietf.orgmailto:kit...@ietf.org Kopie (CC): t...@psaux.commailto:t...@psaux.com t...@psaux.commailto:t...@psaux.com Hi all, as one of the proposers (beside Hannes) of the change, I would like to explain the rationale. -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the oauth-configuration definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.comhttp://outlook.com/ implementations. Existing implementations at Google and Outlook.comhttp://outlook.com/ are no evidence against dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security. Why does this require dynamic registration? Well, OAuth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ -- COMMENT: -- 3 - Assertions used in the protocol exchanges defined by this specification MUST always be protected against tampering using a digital signature or a keyed message digest applied by the issuer. Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions? Indeed, why would a self-issued Bearer Assertion need to be signed at all? Does that even make sense? 4.1 - grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, as it happens, doesn't use 2119 language for this). s/MUST/will assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. The serialization MUST be encoded for transport within HTTP forms. It is RECOMMENDED that base64url be used. The MUST seems weird here. Are you saying that the profile could not possibly have a serialization for an assertion that did not require further encoding? But the RECOMMENDED seems downright wrong: Either an implementer *needs* to know the encoding independently of the profile, and therefore this needs to be a MUST, or the profile is going to describe the encoding, which could be base64url or could be something else, and the implementation will do whatever the profile says. If you really want to say something here, I suggest replacing the last two sentences with: If the assertion is going to be transported within HTTP forms, the profile document needs to describe what (if any) encoding will be needed to do so. The base64url encoding is widely implemented and therefore suggested. scope [...] As such, the requested scope MUST be equal or lesser than the scope originally granted to the authorized accessor. s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason) If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor. The Authorization Server MUST limit the scope of the issued access token to be equal or lesser than the scope originally granted to the authorized accessor. In the first sentence, is this MUST for the server? (That is, shouldn't it be, If the scope parameter and/or value are omitted, the server MUST use the value of the scope originally granted to the authorized accessor.?) And anyway, don't these two sentences contradict 6749, which says: The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. [...] If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. Here and throughout: s/non-normative example/example (As far as I know, there are no other kinds in IETF documents.) 4.1.1 - s/MUST construct/constructs 4.2, client_assertion_type and client_assertion: See comments from 4.1 regarding grant_type and assertion. 4.2.1 - s/MUST construct/constructs 5.2 - s/MUST identify/identifies For clarification: OLD Assertions that do not identify the Authorization Server as an intended audience MUST be rejected. NEW The Authorization Server MUST reject any assertion that does not contain the its own identity as the intended audience. END ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. The first MUST be is obviously silly and should simply be is. But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience. Subpoint 5: OLD The SubjectConfirmation element MUST contain a SubjectConfirmationData element, unless the Assertion has a suitable NotOnOrAfter attribute on the Conditions element, in which case the SubjectConfirmationData element MAY be omitted. That one's sure to get misquoted somewhere and confuse someone. Instead: NEW If the Assertion does not have a suitable NonOnOrAfter attribute on the Conditions element, the SubjectConfirmation element MUST contain a SubjectConfirmationData element. Subpoint 6: OLD The authorization server MUST verify that the NotOnOrAfter instant has not passed, subject to allowable clock skew between systems. An invalid NotOnOrAfter instant on the Conditions element invalidates the entire Assertion. An invalid NotOnOrAfter instant on a SubjectConfirmationData element only invalidates the individual SubjectConfirmation. NEW The authorization server MUST reject the entire Assertion if the NotOnOrAfter instant on the Conditions element has passed (subject to allowable clock skew between systems). The authorization server MUST reject the SubjectConfirmation (but MAY still use the rest of the Assertion) if the NotOnOrAfter instant on the SubjectConfirmationData has passed (subject to allowable clock skew). Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Subpoint 9: As I asked in the -assertions document, is this really a requirement? Subpoint 11: Again, it would be better to put the MUST on the action (e.g., MUST reject) to make it clear who is doing what. 3.1/3.2 - s/MUST construct/constructs 4 - s/Though non-normative// 9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are Normative, not Informative. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT)
Pete Resnick has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ -- COMMENT: -- I'm not going to repeat stuff that is identical to draft-ietf-oauth-saml2-bearer (and I did find that using https://www.ietf.org/rfcdiff?url1=draft-ietf-oauth-saml2-bearer-21difftype=--htmlsubmit=Go%21url2=draft-ietf-oauth-jwt-bearer-10 was very helpful). Please refer to my comments on that document. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT)
Barry Leiba has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ -- COMMENT: -- Pete did a nice job on the 2119 key words, so I have nothing to add there. -- Section 6.1 -- The example in Section 4.2 that shows a client authenticating using an assertion during an Access Token Request. Is that an extra word that should be removed? (Also in Section 6.3.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
