[OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-02.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 WG of the IETF. Title : Reciprocal OAuth Author : Dick Hardt Filename: draft-ietf-oauth-reciprocal-02.txt Pages : 7 Date: 2019-07-03 Abstract: There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seamless experience for the user to grant access to a pair of protected resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-02 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-reciprocal-02 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] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwsreq-19: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ -- DISCUSS: -- My apologies; my previous position was incomplete. Updated to note namespacing issues, and one minor terminology nit about "DNS-ID". There seem to be some pretty serious namespacing issues that are not discussed at all in this document. Specifically, using JWT as a container for OAuth 2.0 authorization request parameters (including extension parameters) introduces the usage of many new names (of JSON name/value pairs) into the JWT claims namespace. Furthermore, the addition is not bounded, as any new OAuth extension parameters are implicitly permitted to be used as well! The IANA Considerations make no mention of the collapsed namespace for JWT claims and OAuth 2.0 (authorization request) parameters, leaving substantial potential for collisions in the future. Relatedly, using "application/jwt" as the Content-type of the HTTP response from dereferencing the request_uri with no explicit indication of the type/profile of JWT used (whether in the content type or in the JWT claims themselves) gives some risk of misinterpretation of the content. Consider, for example, when that request_uri is dereferenced not by the authorization server in the process of fulfilling an authorization request, but instead by some other service that expects a different type of JWT. This second point is a "discuss discuss" -- it's an important question and I'd like to talk about it, but it's not clear that any change to the document will be needed. The introduction notes as an advantage of JWT that: (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. I'm pretty uncomfortable about suggesting that the authorization dialogue can/should be skipped; do we need to keep this example? -- COMMENT: -- Section 1 While it is easy to implement, the encoding in the URI does not allow application layer security with confidentiality and integrity protection to be used. While TLS is used to offer communication nit: this wording is a little hard to read; it might be easier to reorder to "does not allow application layer security to be used to provide confidentiality and integrity protection". The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. (side note) what would an example of such a third party be. (We already have the resource owner, the client, and the authorization server ... maybe it's a fourth party?) Furthermore, the request by reference allows the reduction of over- the-wire overhead. We only barely mentioned by-reference at this point (one line in the Abstract), so I'd suggest "passing the request by reference". (4) its development status that it is an RFC and so is its associated signing and encryption methods as [RFC7515] and [RFC7516] nit: I'd suggest "its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]." (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another. nit: TLS is always terminated at or before the user-agent, though. So maybe the user agent needs to get called out here as well (there could of course be TLS termination earlier than the user-agent in some cases, too). 2. When
Re: [OAUTH-WG] OAuth 2.0 UI/UX Resources?
Hello Daniel, you may gather inspiration and explore Auth0's flows all-in-one page at https://flows.auth0.com Best, *Filip Skokan* On Wed, 3 Jul 2019 at 16:26, Daniel Roesler wrote: > Howdy all, > > Apologies if this is slightly off topic. > > I'm a part of the Green Button Alliance, the non-profit standards body > around sharing energy data, and the customer consent process is based > on OAuth 2.0 (e.g. granting access to your smart meter data in order > to have an energy audit done). > > However, most utilities we work with are unfamiliar with OAuth 2.0, so > we often have to explain how it works and what the best practices are. > There are plenty of resources we can point them to for the actual > protocol handshake, but I haven't been able to find any resources > around best practices for designing the user interface and experience > of OAuth. Unfortunately, in the energy industry, UI/UX design isn't > our strong suit, so it would be very helpful if we had design > lessons-learned from other industries to use as a reference. > > Does anyone here know of any resources, talks, blog posts, examples, > etc. for making good OAuth 2.0 UI/UX? > > Thanks! > Daniel Roesler > > ___ > 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] OAuth 2.0 UI/UX Resources?
Howdy all, Apologies if this is slightly off topic. I'm a part of the Green Button Alliance, the non-profit standards body around sharing energy data, and the customer consent process is based on OAuth 2.0 (e.g. granting access to your smart meter data in order to have an energy audit done). However, most utilities we work with are unfamiliar with OAuth 2.0, so we often have to explain how it works and what the best practices are. There are plenty of resources we can point them to for the actual protocol handshake, but I haven't been able to find any resources around best practices for designing the user interface and experience of OAuth. Unfortunately, in the energy industry, UI/UX design isn't our strong suit, so it would be very helpful if we had design lessons-learned from other industries to use as a reference. Does anyone here know of any resources, talks, blog posts, examples, etc. for making good OAuth 2.0 UI/UX? Thanks! Daniel Roesler ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
Okay, -15 has been published and incorporates those fixes and suggestions: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15 On Mon, Jun 24, 2019 at 5:04 PM Brian Campbell wrote: > Thanks Roman, I'll work to incorporate those suggestions into the next > revision before the impending I-D submission cutoff date. > > On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw wrote: > >> Hi Brian! >> >> >> >> My response is inline ... >> >> >> >> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] >> *Sent:* Monday, June 24, 2019 1:17 PM >> *To:* Roman Danyliw >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls >> >> >> >> Thanks for the additional review, Roman. I feel lucky, it's not often one >> gets *two* AD reviews :) Please see below for replies inline with a few >> followup questions. >> >> >> >> [Roman] *chuckle* >> >> >> >> On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw wrote: >> >> Hi! >> >> I conducted as second AD review of draft-ietf-oauth-mtls per the AD >> hand-off. I have the following additional feedback: >> >> ** Per ekr's earlier review at >> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing: >> -- Section 2.1.2, How is these metadata parameters being obtained? >> >> >> >> The authorization server can obtain client metadata via the Dynamic >> Client Registration Protocol [RFC7591], which is referenced in the top of >> that section. Also the metadata defined by RFC7591, and registered >> extensions to it, implies a general data model for clients that is used by >> most authorization server implementations even when the Dynamic Client >> Registration Protocol isn't in play. Such implementations typically have >> some sort of user interface available for managing client configuration.. >> >> >> >> Dose that answer your question? Do you believe more should be said in the >> document to better explain or clarify that? >> >> >> >> [Roman] It does clear it up. Thanks. I think it’s worth a short >> statement about how the AS would get the fields. >> >> >> >> >> >> -- Section 3.2, Figure 3. In this example, what new information is the >> auth server providing to the relying party here? >> >> >> >> The new info here (and in Section 3.1 too) is the hash of the client >> certificate to which the access token is bound, which is in the "cnf" >> confirmation method at the bottom as the "x5t#S256" member. >> >> >> >> [Roman] Makes sense. To make the example clearer, I’d call out this out >> in the prose introducing the example. >> >> >> >> >> ** Section 2.0. What is the expected behavior if the presented >> certificate doesn't match expected client_id? How is this signaled? >> >> >> >> With a normal OAuth 2.0 error response using the "invalid_client" error >> code per https://tools.ietf.org/html/rfc6749#section-5.2 >> >> >> >> Do you think that needs to be stated more explicitly in this document? >> >> >> >> [Roman] Yes, I’d explicit state it with that citation, especially since >> Section 3 discusses of how errors are returned. >> >> >> >> >> ** Section 2.2. Per the sentence "As pre-requisite, the client registers >> its X.509 certificate ... or a trusted source for its X.509 certificates >> ... with the authorization server. >> -- Editorial: s/As pre-requisite/As a prerequisite/ >> >> >> >> done >> >> >> >> -- What's a "trusted source" in this case? Is that just a jwks_uri? If >> so, maybe s/a trusted source/a reference to a trust source/. If not, can >> you please elaborate. >> >> >> >> Yes, it's just a jwks_uri. I'll change that. >> >> >> >> >> A few editorial nits: >> ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ >> >> >> >> fixed >> >> >> >> >> ** Section 3.1 Cite DER encoding as: >> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: >> Specification of Basic Encoding Rules (BER), Canonical >> Encoding Rules (CER) and Distinguished Encoding Rules >> (DER)", ITU-T Recommendation X.690, 2015. >> >> >> >> will do >> >> >> >> ** Section 5. Typo. s/metatdata/metadata/ >> >> >> >> yup >> >> >> >> >> ** Section 6. Typo. s/The the/The/ >> >> >> >> got it >> >> >> >> >> ** Section 7.2. Typo. s/the the/the/ >> >> >> >> done >> >> >> >> >> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the >> contents of the section. >> >> >> >> will do >> >> >> >> >> The shepherd write-up is in good shape. Thank you. >> >> Regards, >> Roman >> >> >> >> [Roman] Thanks for all of the above. >> >> >> >> Roman >> >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited.. >> If you have received this communication in error, please notify the sender >> immediately b
[OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-15.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 WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename: draft-ietf-oauth-mtls-15.txt Pages : 30 Date: 2019-07-03 Abstract: This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15 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
