Re: [OAUTH-WG] OAuth2 Client Discovery

[Tobias Looker]

> 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]



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global

[Mattr 
website]

[Mattr on 
LinkedIn]

[Mattr on 
Twitter]

[Mattr on 
Github]

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 
Sent: 16 December 2022 09:52
To: Tobias Looker 
Cc: 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  
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

Re: [OAUTH-WG] OAuth2 Client Discovery

[Tobias Looker]

Hi Vladimir,

> OAuth 2.0 and OIDC originally have a model where the client metadata is made 
> to match the server's requirements and supported algorithms.

Agreed.

> For a client to publish metadata tailored to one particular OP / AS server 
> doesn't appear to be much of a problem.  How do you envision a scenario when 
> the client developer wants to enable different OP / AS servers, where the 
> supported algs and other capabilities may differ? Here one strategy could be 
> to make the metadata as general as possible, but then this may lead to 
> registration errors due to incomplete metadata. Incomplete metadata can also 
> cause the server to pick a default value that suits its capabilities, but 
> because there is no explicit client registration response the client has no 
> way to find out how it got registered, which may then lead to errors in the 
> OAuth flow.

One option is for the client to publish everything it supports in its metadata 
document(s) that different AS's can use to assess compatible and pick which 
various features to use. I agree incomplete metadata could cause 
incompatibility issues and depending on how strong we want to be in defining 
this mechanism we could opt for a larger set of metadata being required by a 
client to lessen the risk of these sorts of incompatibilities arising. IMO just 
like the incentives at play for an AS to publish a well defined metadata 
document that reduces the potential for incompatibilities, a client developer 
using this mechanism will be in a similar boat, more metadata published about 
the client will mean less potential for bad assumptions being made by the AS.

> My second question - if basic auth is regarded as possible with static client 
> metadata discovery, how can the client and server establish a secret between 
> them?

This is a good catch, w.r.t client authentication I suspect signed requests 
where the client uses a private key, who's public keys are fetchable from its 
JWK's endpoint is going to be a better pattern then a shared secret with the 
AS, will update this section.


Thanks,

[Mattr 
website]



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global

[Mattr 
website]

[Mattr on 
LinkedIn]

[Mattr on 
Twitter]

[Mattr on 
Github]

This communication, including any attachments, is confidential. If you are not 
the intended recipient, you should not rea

Re: [OAUTH-WG] OAuth2 Client Discovery

[Dick Hardt]

On Thu, Dec 15, 2022 at 12:39 PM Tobias Looker 
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

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Torsten Lodderstedt]

Hi Robert, 

Thanks for your review. 

> Am 15.12.2022 um 11:37 schrieb Robert Wilton via Datatracker 
> :
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-oauth-rar-20: No Objection
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Apologies, but I was a bit short of time this week, and this is somewhat out 
> of
> my area, so I've only reviewed this as a light level.
> 
> I did have one question regarding the security considerations.  Are these JSON
> structures potentially susceptible to injection attacks if user input isn't
> properly sanitized and handled, and if so, should there be any text in the
> security section to warn of this?

Added the following text to the Security Considerations Section: 

"The AS MUST properly sanitized and handle the data passed in the
   authorization_details in order to prevent injection attacks.“

https://author-tools.ietf.org/iddiff?difftype=--hwdiff&url2=draft-ietf-oauth-rar-21.txt

best regards,
Torsten. 

> 
> Regards,
> Rob
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Torsten Lodderstedt]

Hi Eric,

> Am 15.12.2022 um 11:33 schrieb Éric Vyncke via Datatracker :
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-oauth-rar-20: No Objection
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-oauth-rar-19
> CC @evyncke
> 
> Thank you for the work put into this document. It is very easy to read and
> quite powerful.
> 
> Please find below one non-blocking COMMENT point (rather a suggestion).
> 
> Special thanks to Hannes Tschofenig for the shepherd's detailed write-up
> including the WG consensus ***but*** missing the justification of the intended
> status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> ### Section 1
> 
> I like the use of EUR rather than USD ;-)

:-) 

> 
> Suggest to also add "bic" in addition to "iban" to be consistent with
> https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

added bic the example (even though it’s not required for German bank accounts 
even cross border ;-))

https://author-tools.ietf.org/iddiff?difftype=--hwdiff&url2=draft-ietf-oauth-rar-21.txt

thanks,
Torsten. 

> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-21.txt

[internet-drafts]

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 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
  Filename: draft-ietf-oauth-rar-21.txt
  Pages   : 46
  Date: 2022-12-15

Abstract:
   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-21.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-rar-21


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 Client Discovery

[Vladimir Dzhuvinov]

Hi Tobias,


OAuth 2.0 and OIDC originally have a model where the client metadata is 
made to match the server's requirements and supported algorithms.



This looks roughly like this:

 * The server has its metadata published at the well-known URL.

 * The client developer examines the server metadata it to see what is
   supported and required and will create a compliant registration.

 * If the client is going to use client_secret_basic,
   client_secret_post or client_secret_jwt auth the server will
   provision a client_secret.


For a client to publish metadata tailored to one particular OP / AS 
server doesn't appear to be much of a problem.  How do you envision a 
scenario when the client developer wants to enable different OP / AS 
servers, where the supported algs and other capabilities may differ? 
Here one strategy could be to make the metadata as general as possible, 
but then this may lead to registration errors due to incomplete 
metadata. Incomplete metadata can also cause the server to pick a 
default value that suits its capabilities, but because there is no 
explicit client registration response the client has no way to find out 
how it got registered, which may then lead to errors in the OAuth flow.



If the error manifests at the token endpoint, where for instance the 
client registered for private_key_jwt auth, but the server picked a JWS 
alg which the client doesn't support, or isn't aware of because the 
token_endpoint_auth_signing_alg has no fixed standard default value, the 
client will get an invalid_client error.



If the client registration failed because the discovered metadata was 
rejected, the server (if remaining compliant with RFC 6749) will not 
redirect the user back to the client. The UX risk of that may not be 
acceptable for some clients.




My second question - if basic auth is regarded as possible with static 
client metadata discovery, how can the client and server establish a 
secret between them?




Clients in
possession of a client password MAY use the HTTP Basic authentication
scheme as defined in RFC 2617 [RFC2617] or MAY include the client
credentials in the request-body to authenticate with the
authorization server.




~ Vladimir


On 09/11/2022 00:22, Tobias Looker wrote:

Hi All,

I would like to draw attention to a new I-D we've recently updated 
called "OAuth2 Client Discovery".


https://datatracker.ietf.org/doc/draft-looker-oauth-client-discovery/01/

Below is the drafts current abstract for context:

"This specification defines a mechanism for an authorization server to 
obtain the metadata of a client, including its endpoint locations and 
capabilities without the need for a registration process."


Further motivation can be found in the drafts introduction. We believe 
the draft is relevant to the presentation Kristina will be making 
tomorrow on "client_id" as a URI, hence the email promoting awareness 
of it.


There is also important discussion in the current open issues for the 
I-D, including those discussing its compatibility with other 
specifications that overlap. 
https://github.com/mattrglobal/draft-looker-oauth-client-discovery/issues


Thanks,

Mattr website 







*Tobias Looker*

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global 

Mattr website 





Mattr on LinkedIn 





Mattr on Twitter 

[OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-oauth-rar-20: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/



--
COMMENT:
--

Hi,

Apologies, but I was a bit short of time this week, and this is somewhat out of
my area, so I've only reviewed this as a light level.

I did have one question regarding the security considerations.  Are these JSON
structures potentially susceptible to injection attacks if user input isn't
properly sanitized and handled, and if so, should there be any text in the
security section to warn of this?

Regards,
Rob



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Éric Vyncke's No Objection on draft-ietf-oauth-rar-20: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-oauth-rar-20: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/



--
COMMENT:
--


# Éric Vyncke, INT AD, comments for draft-ietf-oauth-rar-19
CC @evyncke

Thank you for the work put into this document. It is very easy to read and
quite powerful.

Please find below one non-blocking COMMENT point (rather a suggestion).

Special thanks to Hannes Tschofenig for the shepherd's detailed write-up
including the WG consensus ***but*** missing the justification of the intended
status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

I like the use of EUR rather than USD ;-)

Suggest to also add "bic" in addition to "iban" to be consistent with
https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-rar-19: (with COMMENT)

[Torsten Lodderstedt]

Hi Murray, 

thanks for you review. 

I updated the draft based on it and submitted -20

Here is the diff 
https://author-tools.ietf.org/iddiff?difftype=--hwdiff&url2=draft-ietf-oauth-rar-20.txt

> Am 15.12.2022 um 09:34 schrieb Murray Kucherawy via Datatracker 
> :
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-oauth-rar-19: No Objection
> 
> 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for the work put into this.  Seems like it's in good shape.
> 
> Thank you to Thomas Fossati for the ARTART review.
> 
> "MUST consider" in Section 3.1 is curious.  How does an implementation comply
> with something like "consider"?

Good point, what we want to get across is that the AS must not ignore any of 
the requirements defined in a scope or authorization details parameter if both 
are present in the authorisation request. 

Changed it to „process".

> 
> Why is the "RECOMMENDED" in Section 9.1 not a MUST?  The text in Section 9 
> just
> above it suggest something stronger.

The AS is free to choose the format and representation of the data. It is not 
required to use the authorization details structure, it can transform and 
filter it. 

> 
> In Section 7.1, I can't understand what's meant by "This mechanic ...".

Changed it to „This example“. 

best regards,
Torsten.   

> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-rar-20.txt

[internet-drafts]

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 Rich Authorization Requests
Authors : Torsten Lodderstedt
  Justin Richer
  Brian Campbell
  Filename: draft-ietf-oauth-rar-20.txt
  Pages   : 46
  Date: 2022-12-15

Abstract:
   This document specifies a new parameter authorization_details that is
   used to carry fine-grained authorization data in OAuth messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-rar-20.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-rar-20


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-rar-19: (with COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-oauth-rar-19: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/



--
COMMENT:
--

Thanks for the work put into this.  Seems like it's in good shape.

Thank you to Thomas Fossati for the ARTART review.

"MUST consider" in Section 3.1 is curious.  How does an implementation comply
with something like "consider"?

Why is the "RECOMMENDED" in Section 9.1 not a MUST?  The text in Section 9 just
above it suggest something stronger.

In Section 7.1, I can't understand what's meant by "This mechanic ...".



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth