> Don't you think the AS should state what it requires in a client discovery > call as well?
I guess I'm trying to understand what exactly this would be and where one would draw the line, for example would the AS simply publish a list of required client metadata properties OR a list of metadata properties and the valid enumeration for each property? The whole purpose of the AS metadata document in the first place is for the AS to publish what it supports, so I'm trying to drill into what is missing. > Why not? Because RFC 6749 🙂 > I also prioritize developers using libraries of client library developers. If > I as a consumer of a library am wanting to use client discovery and I happen > to be using a library that does not support it -- it will give me an error > right away because I did not get a client_id. I think the point I was trying to make is that if we re-use client_id then there won't be any need to update client libraries to support client discovery and I think that resolves a significant adoption challenge. > You view client discovery as incremental -- I consider it to be a significant > shift. For example, clients are going to authenticate (if needed) with a > signed request vs using a secret. Understood I think that's correct. 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: Dick Hardt <dick.ha...@gmail.com> Sent: 16 December 2022 09:52 To: Tobias Looker <tobias.looker@mattr.global> Cc: oauth@ietf.org <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. On Thu, Dec 15, 2022 at 12:39 PM Tobias Looker <tobias.looker@mattr.global> wrote: > Would be good to see tos_uri and policy_uri (personally, I'm disappointed in > the name policy_uri as policy is a much broader context than privacy -- but > that discussion is over =) Ok so to be clear you are suggesting we update the non-normative example in the spec to include a tos_uri and policy_uri? Happy to. yes, thanks! > If one of the goals is for a client to work with an arbitrary AS, then we > need the client to know if it has what the AS needs before send the user > there, otherwise it is a bad UX as the AS tells the user the client is not > supported. This leads to the AS publishing required and understood metadata > that it needs. I agree the more that can be decided before the users UX is at stake is better. I think adding an element to an AS's metadata document that indicates whether the AS supports client discovery is worthwhile but beyond this should be left to future enhancement (e.g AS's policies about what clients it is willing to interact with). Don't you think the AS should state what it requires in a client discovery call as well? > My proposal has one parameter for the two required in your case. My point is that my proposal only has one new parameter, the other is existing and required by the protocol, an authorization request without a client_id isn't OAuth2 is it? Why not? > A server telling me that client_id is required clearly does not support > client discovery. I'd argue so does a server telling me "client not found" when I sent it an Authz request including the client_discovery parameter 🙂. > Forgetting to provide the client_discovery parameter (or mispelling it) is a > likely mistake, which has the AS think it does not do client discover, and > provide an error of client_id not found -- although many implementations > will just throw up and report an unrelated error if the client_id is not > found -- I recently had that issue with Instagram where I was sending the > wrong client_id -- but it gave me a generic error. Same risk applies to mis-spelling the client_uri parameter in either of our proposals there is a new parameter. > I would prioritize ease of simplicity for client developers over AS > developers. The code path for client_uri is quite different than for > client_id as the prior is doing discovery (or working with a cache) and the > latter is doing a DB lookup. I see no difference in effort for me in AS > development -- but I write my own implementations. =) I see both as resolving an identifier for the client to its metadata, one is doing this via DB lookup another might be making a network call (through a caching layer). Considering client developers for a second, re-using client_id and adding a new parameter is far more likely to result in being able to re-use existing client libraries, because most support additional request parameters, so you can add the required client_discovery parameter. However I suspect most existing libraries wont allow you to not include client_id in the authz request because its required by OAuth2. So in that sense I think re-using client_id is also infact simpler for client developers/implementers. I also prioritize developers using libraries of client library developers. If I as a consumer of a library am wanting to use client discovery and I happen to be using a library that does not support it -- it will give me an error right away because I did not get a client_id. You view client discovery as incremental -- I consider it to be a significant shift. For example, clients are going to authenticate (if needed) with a signed request vs using a secret. We don't need to resolve this now. We can see what others have to say. / Dick
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
