Re: [OAUTH-WG] Meeting Minutes
Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. That was not the consensus as I understood it in the room. The consensus was the first portion, as originally noted. The second portion was Mike’s requested amendment, and it (and other aspects like the value of token_type) were brought up as details that the editors would work on and come back to the list. — Justin On Jul 25, 2015, at 7:07 AM, Mike Jones michael.jo...@microsoft.com wrote: Good notes. Please apply the following fixes to them... To the list of new OAuth RFCs since the last meeting please also add: draft-ietf-oauth-json-web-token draft-ietf-oauth-saml2-bearer draft-ietf-oauth-jwt-bearer Please change: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always the same token. to: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always an access token. Please change: Consensus: For use of existing params defined in OAuth. to: Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. Please change: Mike: Microsoft oauth2 server have a 'resource' param to indicate the audience. to: Mike: Microsoft oauth2 server has a 'resource' param to indicate the resource that the access token will be used to access. whitely used - widely used We need to go on with out lives - We need to go on with our lives ready to a shepherd write-up - ready for a shepherd write-up Finally, I would add a note saying: Some additional drafts are planned, including draft-jones-amr-values and draft-ietf-oauth-discovery Thanks -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, July 23, 2015 7:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] Meeting Minutes Here are the notes from our meeting yesterday: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fproceedings%2f93%2fminutes%2fminutes-93-oauthdata=01%7c01%7cMichael.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o2BmH5Kv8%3d Thanks to Erik for taking notes. Please let me know if something is missing or incorrect within the next 2 weeks. 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
Re: [OAUTH-WG] Meeting Minutes
My sense of the consensus in the room is as Justin describes it. On Sat, Jul 25, 2015 at 9:14 AM, Justin Richer jric...@mit.edu wrote: Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. That was not the consensus as I understood it in the room. The consensus was the first portion, as originally noted. The second portion was Mike’s requested amendment, and it (and other aspects like the value of token_type) were brought up as details that the editors would work on and come back to the list. — Justin On Jul 25, 2015, at 7:07 AM, Mike Jones michael.jo...@microsoft.com wrote: Good notes. Please apply the following fixes to them... To the list of new OAuth RFCs since the last meeting please also add: draft-ietf-oauth-json-web-token draft-ietf-oauth-saml2-bearer draft-ietf-oauth-jwt-bearer Please change: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always the same token. to: Mike: If the access_token is used, then we must add to spec that it's there for historic reasons and say that it's actually not always an access token. Please change: Consensus: For use of existing params defined in OAuth. to: Consensus: For use of existing params defined in OAuth, while allowing some to be optional when not needed. Please change: Mike: Microsoft oauth2 server have a 'resource' param to indicate the audience. to: Mike: Microsoft oauth2 server has a 'resource' param to indicate the resource that the access token will be used to access. whitely used - widely used We need to go on with out lives - We need to go on with our lives ready to a shepherd write-up - ready for a shepherd write-up Finally, I would add a note saying: Some additional drafts are planned, including draft-jones-amr-values and draft-ietf-oauth-discovery Thanks -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, July 23, 2015 7:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] Meeting Minutes Here are the notes from our meeting yesterday: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fproceedings%2f93%2fminutes%2fminutes-93-oauthdata=01%7c01%7cMichael.Jones%40microsoft.com%7ccb085108ecb0454b33c008d293699b85%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=5GiVy2SivZk6GWeoXtabbQG1q3r1%2bL%2fnM4o2BmH5Kv8%3d Thanks to Erik for taking notes. Please let me know if something is missing or incorrect within the next 2 weeks. 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Authentication Method Reference Values Specification
There's a method of authentication that is gaining in popularity which I'd propose adding a method for. It is typically used as a second factor where after a primary auth, like username and password, a push notification is sent to the user's phone and they acknowledge it from the device. We have the PingID product https://www.pingidentity.com/en/products/pingid.html that does it and Entrust http://www.entrust.com/resource/entrust-identityguard-mobile-push-authentication-for-vpn-and-web-access and Duo https://www.duosecurity.com/product/methods/duo-mobile, among others I'm sure, offer something similar. It's commonly called mobile push authentication so maybe mpa could be the amr value. But, as Nat pointed out, the really interesting characteristic is that it's a second factor that utilizes only a secondary channel - so perhaps sca for second channel authentication would be a more appropriate general amr name. Thoughts are welcome. But I believe it's becoming prevalent enough that it deserves its own amr value in this doc. On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones michael.jo...@microsoft.com wrote: I agree that an obvious good thing to do is to add spec references to the field definitions. I need to investigate use cases for amr_values. I think this came from developers who actually wanted this for a particular purpose but I’ll have to get back to the WG on that. It’s defined here, rather than in another spec, because it’s highly related to the “amr” values. -- Mike *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura *Sent:* Thursday, July 23, 2015 6:22 PM *To:* William Denniss *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values Specification So, allow me a naive question. I supppose there are good random otp, as well as pretty bad otp etc. Would it be useful to say just otp. Would it not be better to have at least a field that references a spec that specifies the security requirement for that mechanism? 2015-07-23 12:05 GMT+02:00 William Denniss wdenn...@google.com: Thanks for drafting this Mike. I'm in favor of having this registry. In addition to the specific values, I propose we add some generic ones too (trying to follow your naming scheme): rba: risk-based auth upt: user presence test My fear of making things too specific is that RPs may get lost in the weeds trying to work out what things they should care about and how. As an IdP we like to guide RPs through these kinds of decisions, and prefer to pass a more high level indication of what happened (such as these two values). If someone wanted to have best of both worlds, then both could be asserted, e.g. upt fpt to indicate that the user presence was tested, using a fingerprint test. Regarding the proposed wia value. I don't know what it is, and the spec doesn't help me find out, can a reference be added? I also wonder if it could be genericized to avoid being vendor specific values – but mostly I just want to understand what it is. Almost all the other values are self-explanatory, perhaps pop could use a reference as well (or maybe just a longer explanation). I don't see the immediate value of amr_values, can you elaborate with some places where this would be applied? Separately, I wonder if an extension to OIDC should be included in this doc, which is otherwise a fairly clean registry spec that could be used more broadly. On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell bcampb...@pingidentity.com wrote: So maybe a naive question but why does this draft define amr_values while also suggesting that it's fragile and that acr acr_values is preferable? Seems contradictory. And I doubt I'm the only one that will find it confusing. On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones michael.jo...@microsoft.com wrote: The key part of this is establishing a registry. That can only be done in an RFC. John, I encourage you to submit text beefing up the arguments about why using “acr” is preferable. The text at http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationshipdata=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=6%2blPSyG0xfBMg0jxKaQt1lAcW6GV3%2fje4dmkE%2bb7Q8o%3d is a start at that. -- Mike *From:* John Bradley [mailto:ve7...@ve7jtb.com] *Sent:* Thursday, July 23, 2015 9:30 AM *To:* Justin Richer *Cc:* Mike Jones; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values Specification I don’t personally have a problem with people defining values for AMR and creating a IANA registry. That
