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
