> While we're talking about prior art, I should also mention that the IndieAuth > extension of OAuth 2 has been using URLs as client IDs since about 2012. > (Disclosure: I am the editor of the spec)
> Since 2012, the spec has matured and was published as a W3C Note in 2018 > while the W3C Social Web Working Group was active. > (https://www.w3.org/TR/indieauth/) Currently, the spec is maintained in the > IndieWeb community, the latest update was in February 2022: > https://indieauth.spec.indieweb.org/20220212/ Is there an accepted way to reference prior art in an I-D I'd like to be able to highlight IndieAuth, Solid and OpenID Federation all as examples of slightly different ways this problem is being solved in the wild today. > For this reason, the IndieAuth spec has put far less emphasis on client > metadata discovery vs making the rest of the OAuth flow work by having the > client_id be a URL. There is a method of client metadata discovery defined, > but it's always secondary to making sure the user can see the redirect URL > (or the client identifier if it has the same hostname as the redirect URL), > since ultimately that is where the authorization code will be sent. In general I agree, one thing I would note is does the user need to see the redirect URL? In the client discovery model I would assume the identifier surfaced by the AS to the user, to establish trust in the client, is the client_id (which is taking the form of a URL). Because if you are resolving the clients metadata using this + a well-known path, and you receive a list of permitted redirect_uri's for that client that you can validate the authorization request against? Take the example client_id => https://client.example.com metadata resolved from => https://client.example.com/.well-known/oauth-client supported redirect uri listed in client metadata => https://another-domain.com I would assume the only identifier that is important to surface to the user about the client is https://client.example.com, the redirect uri the client is less of a concern, provided it is validated against the redirect uri's permitted by the client which is listed in its metadata. Thanks, [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> [Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> [Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> [Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. ________________________________ From: Aaron Parecki <aaron=40parecki....@dmarc.ietf.org> Sent: 14 December 2022 16:07 To: oauth@ietf.org <oauth@ietf.org> Cc: Tobias Looker <tobias.looker@mattr.global>; Ben Schwartz <bem...@google.com>; Dmitry Telegin <dmit...@backbase.com> Subject: Re: [OAUTH-WG] OAuth2 Client Discovery EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. While we're talking about prior art, I should also mention that the IndieAuth extension of OAuth 2 has been using URLs as client IDs since about 2012. (Disclosure: I am the editor of the spec) Since 2012, the spec has matured and was published as a W3C Note in 2018 while the W3C Social Web Working Group was active. (https://www.w3.org/TR/indieauth/) Currently, the spec is maintained in the IndieWeb community, the latest update was in February 2022: https://indieauth.spec.indieweb.org/20220212/ Because the premise of this scenario is that the user may have no prior relationship with an application they are authorizing via an OAuth flow, and the applications have no prior relationship with the authorization server, naturally we want to provide as much context to the user about the application as possible. If there is no prior relationship between either the user and client or the client and authorization server, it's an inherently risky situation. Should the user believe any self-asserted information by the client? Probably not. In fact, the only information that the user can truly "verify" is the redirect URL. Any information (name, logo, etc) provided by the client at its client_id URL (regardless of whether that is a .well_known URL or the client_id URL itself as JSON or HTML) ultimately can't be trusted. If the redirect_uri shares the same hostname of the client_id then that's a good sign that nothing phishy is happening. For this reason, the IndieAuth spec has put far less emphasis on client metadata discovery vs making the rest of the OAuth flow work by having the client_id be a URL. There is a method of client metadata discovery defined, but it's always secondary to making sure the user can see the redirect URL (or the client identifier if it has the same hostname as the redirect URL), since ultimately that is where the authorization code will be sent. This is why using a client_id that contains human-readable information is so critical to the security of the flow. When the client_id is something that the user can click on and visit, they can then see more information about which application they are granting access to. It's very common that applications in this space will have a web page about them, at the very least a landing page with links out to app stores, so it's not a huge stretch of the imagination. It's worth thinking about these types of privacy and security considerations of any form of this type of unregistered OAuth client. Aaron Parecki On Tue, Dec 13, 2022 at 9:30 AM Dmitry Telegin <dmitryt=40backbase....@dmarc.ietf.org<mailto:40backbase....@dmarc.ietf.org>> wrote: Hello Tobias, thanks for the draft! In regards to prior art, I'd like to mention Solid Project and their OIDC flavor, Solid-OIDC: https://solid.github.io/solid-oidc/#clientids-document They're using a similar approach (and have been for years), though with some differences: - client_id points to a URL that must resolve to the client metadata document directly (no .well-known/* used); - the document's format is JSON-LD, a superset of JSON. In order to maintain compatibility with Solid and similar existing technologies, would it make sense to mention that: - while retrieving client metadata, AS should recognize not only application/json, but application/ld+json (or maybe even application/*+json, as per https://datatracker.ietf.org/doc/html/rfc6839#section-3-1)? - any unknown fields (like JSON-LD "@context") must be ignored? On an unrelated note, it would be nice to cover the issue of caching the client metadata on the AS side. Obviously, we wouldn't want to re-request the metadata upon every request to the authorization endpoint. Would RFC 9111 suffice here? If so, which subset should be guaranteed to be supported by the AS? Thanks, Dmitry On Wed, Nov 9, 2022 at 8:36 PM Tobias Looker <tobias.looker=40mattr.glo...@dmarc.ietf.org<mailto:40mattr.glo...@dmarc.ietf.org>> wrote: Hi Ben, See below for some thoughts. > I'm having trouble understanding the precise URL structures that are used > here. Can client_uri include a nontrivial path? Why is it necessary to > repeat client_uri in the response JSON? The intent here is to follow how "OAuth 2.0 authorization metadata" works (RFC 8414) which requires the client resolving the authorization server metadata to check that the issuer in the resolved document matches the issuer URL they started the resolution with, see below for the relevant extract from RFC 8414. " The "issuer" value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata. If these values are not identical, the data contained in the response MUST NOT be used. " So the equivalent with our draft is to require the authorization server to validate that the client_uri returned in the clients metadata response matches the URL that was used to retrieve the metadata. > The use of .well-known is a bit unusual. Why not just host the JSON at the > client_uri? Just to clarify it is, just under a well-known path? e.g if the client uri is https://client.example.com then the metadata would be published at https://client.example.com/.well-known/oauth-client > Finally, I note that the section on Impersonation Attacks doesn't mention the > client_name or logo_uri. If these are to be shown to the user, they present > a very serious impersonation risk that ought to be discussed. (The > client_name also might need to be localized, which could be done by fetching > the JSON document with an appropriate Accept-Language request header.) Yes absolutely agree this is an important security consideration to highlight, I will capture an issue. Thanks, [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> [Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> [Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> [Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. ________________________________ From: Ben Schwartz <bemasc=40google....@dmarc.ietf.org<mailto:40google....@dmarc.ietf.org>> Sent: 10 November 2022 07:04 To: Tobias Looker <tobias.looker@mattr.global> Cc: oauth@ietf.org<mailto:oauth@ietf.org> <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] OAuth2 Client Discovery EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
