Re: [OAUTH-WG] OAuth2 Client Discovery

[Tobias Looker]

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



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 

Re: [OAUTH-WG] OAuth2 Client Discovery

[Aaron Parecki]

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

Re: [OAUTH-WG] OAuth2 Client Discovery

[Tobias Looker]

Hi Dmitry,

Thanks for the feedback, it appears there is a lot of conceptual alignment with 
Solids approach.

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

There are certainly things we could explore here, one such option could be to 
continue to only return application/json but for the document to include an 
element like "@context" in the response if its desired that the metadata be 
processable as a JSON-LD document.

> any unknown fields (like JSON-LD "@context") must be ignored?

Yeah this aligns with the data extensibility model anyway e.g "ignore what you 
don't understand" so I don't see any issue with this.

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

Yes I've had similar thoughts about this, I think RFC 9111 could be a good 
basis. What remains a little unclear to me is what normative requirements we 
might impose on implementers in regards to caching, for instance I think 
requiring clients hosting their metadata to implement HTT request caching would 
be too strict, but if they are to implement it, RFC 9111 is recommended and if 
you do here is how it must be implemented?

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: Dmitry Telegin 
Sent: 14 December 2022 06:30
To: Tobias Looker 
Cc: Ben Schwartz ; 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-WG] Step-up Authentication Shepherd Review

[Rifaat Shekh-Yusef]

Vittorio, Brian,

The following is my document shepherd review for the step-up
authentication document:
https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-06.html


*Comments*

* Section 4, first sentence:


You might have a reason for using MAY, instead of SHOULD, but it is not
obvious to me. Can you add some text to explain the reason for this?


* Section 5

“when it comes to access tokens in this specification it is RECOMMENDED
that the requested acr value is treated as required”

Not sure why this sentence started in such a way. Why not just explicitly
use MUST to make sure that the acr value is included in the access token?


* Section 9, last sentence

I think we need to have a stronger statement here and not leave it wide
open like this.

Maybe state that the resource server SHOULD NOT return a challenge if the
request did not include a valid token?


*Nits*

Section 2 - “not be necessarily hold true” -> drop the “be”

Section 5 - Thee - > The

Section 8 - any undesirable -> an undesirable

Section 9 - {#Challenge} -> fix the reference


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

Re: [OAUTH-WG] OAuth2 Client Discovery

[Dmitry Telegin]

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  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,
>
> [image: Mattr website]
> 
>
>
>
> *Tobias Looker*
>
> MATTR
> CTO
>
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
>
> [image: Mattr website]
> 
>
> [image: Mattr on LinkedIn]
> 
>
> [image: Mattr on Twitter]
> 

Re: [OAUTH-WG] [oauth-ext-review] [IANA #1261154] expert review for draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

[Hannes Tschofenig]

This revision is OK.

Thanks for all the work.

-Original Message-
From: oauth-ext-review  On Behalf Of Amanda 
Baber via RT
Sent: Friday, December 9, 2022 7:25 PM
Cc: wpa...@rhosys.ch; r...@cert.org; oauth@ietf.org; oauth-ext-rev...@ietf.org; 
Hannes Tschofenig ; bcampb...@pingidentity.com
Subject: [oauth-ext-review] [IANA #1261154] expert review for 
draft-ietf-oauth-rar (OAuth Parameters - OAuth Extensions Error)

Hi Hannes,

Is this revision OK?

thanks,
Amanda

On Thu Dec 08 21:53:58 2022, bcampb...@pingidentity.com wrote:
> Thanks for catching that Hannes. I believe you are correct that a
> copy-and-paste error went unnoticed. I have fixed the glitch with a
> draft
> -18 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-18
>
> On Thu, Dec 8, 2022 at 4:16 AM Hannes Tschofenig
> 
> wrote:
>
> > Hi all,
> >
> > Thanks for the email, Amanda.
> >
> > I review the IANA consideration request. Only the OAuth Extension
> > Error registration in Section 15.6 of
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar#name-iana
> > -
> > considerations
> > requires some changes.
> > The other, OAuth-related registry entries, are fine.
> >
> > Here is what the text says for Section 15.6:
> > --
> > 15.6. OAuth Extensions Error registry
> >
> > This specification requests registration of the following value in
> > the IANA "OAuth Extensions Error registry" registry of
> > [IANA.OAuth.Parameters] established by [RFC6749].
> >
> > Metadata Name:
> > invalid_authorization_details
> > Metadata Description:
> > indicates invalid authorization_details_parameter to the client.
> > Change Controller:
> > IETF
> > Specification Document(s):
> > Section 5 of [[ this document ]]
> > --
> >
> > The OAuth Extensions Error registry requires the following
> > information to be provided, see
> >
> > https://www.iana.org/assignments/oauth-parameters/oauth-
> > parameters.xhtml#extensions-error
> >
> > Name:
> > Usage Location:
> > Protocol Extension:
> > Change Controller:
> > Reference:
> >
> > I assume that this is the result of a copy-and-paste error that got
> > unnoticed.
> > I suspect the authors can quickly fix this glitch.
> >
> > Ciao
> > Hannes
> >
> >
> >
> > -Original Message-
> > From: OAuth  On Behalf Of Amanda Baber via
> > RT
> > Sent: Tuesday, December 6, 2022 3:18 AM
> > Cc: oauth@ietf.org; drafts-expert-review-comm...@iana.org;
> > oauth-ext-rev...@ietf.org
> > Subject: [OAUTH-WG] [IANA #1261154] expert review for draft-ietf-
> > oauth-rar (OAuth Parameters - OAuth Extensions Error)
> >
> > Hi Hannes (cc: oauth wg),
> >
> > Have you had a chance to review the registrations for this document?
> > This
> > is listed on the IESG telechat agenda for the 15th.
> >
> > thanks,
> > Amanda
> >
> > On Thu Nov 17 18:09:19 2022, sabrina.tanamal wrote:
> > > Hi Hannes (cc: oauth wg),
> > >
> > > As the designated expert for the OAuth Parameters and OAuth
> > > Extensions Error registries, can you review the proposed
> > > registrations in
> > > draft-
> > > ietf-oauth-rar for us? Please see
> > >
> > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar
> > >
> > > The due date is December 1st.
> > >
> > > If this is OK, when the IESG approves the document for
> > > publication, we'll make the registrations at
> > >
> > > https://www.iana.org/assignments/oauth-parameters
> > >
> > > thanks,
> > >
> > > Sabrina Tanamal
> > > Lead IANA Services Specialist
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose
> > the contents to any other person, use it for any purpose, or store
> > or copy the information in any medium. Thank you.
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >

___
oauth-ext-review mailing list
oauth-ext-rev...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth-ext-review
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [OAUTH-WG] Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: (with COMMENT)

[Francesca Palombini]

Hi Justin, Brian,

Thank you for your answers! It makes sense not include it if you believe it 
would confuse the readers, just thought I would point it out in case you had 
not seen it.

Francesca

From: Justin Richer 
Date: Monday, 12 December 2022 at 19:48
To: Brian Campbell 
Cc: Francesca Palombini , The IESG 
, draft-ietf-oauth-...@ietf.org , 
oauth-cha...@ietf.org , oauth@ietf.org , 
hannes.tschofe...@arm.com , 
hannes.tschofe...@gmx.net 
Subject: Re: Francesca Palombini's No Objection on draft-ietf-oauth-rar-18: 
(with COMMENT)
Apologies, sending from the correct email account this time. Please do not 
reply to the other address.

Thank you,
 — Justin


On Dec 12, 2022, at 1:45 PM, Justin Richer 
mailto:jus...@richer.org>> wrote:

Francesca,

Thanks for the pointer! I read through the referenced RFC as well and I agree 
with Brian’s take. I don’t think there’s enough similarity in the domain or the 
solution to warrant a meaningful comparison here. It seems that RFC9237 was not 
written in such a way as for it to be generally applicable, and that seems to 
be the intentional design. Section 2.2 of that document specifically states 
that it’s limited in a number of ways, such as the statement that it’s for 
"statically identifiable objects”. These limitations seem to put it in a 
squarely different camp from RAR, which is intended to allow expression of 
general-purpose security elements across many different styles of APIs. The 
various examples in the RAR draft should, hopefully, make that clear.

I personally think that mentioning RFC9237 would only confuse readers of this 
specification.

 — Justin


On Dec 12, 2022, at 1:22 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks Francesca,

I must admit that I was not aware of RFC9237. After a quick look, however, it 
really is intended for Ace and IoT (as you point out) and I don't believe I 
could write anything sufficiently meaningful about any similarities to this 
document to warrant inclusion.

On Mon, Dec 12, 2022 at 9:10 AM Francesca Palombini via Datatracker 
mailto:nore...@ietf.org>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-oauth-rar-18: 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:
--

Thank you for the work on this document.

Many thanks to Thomas Fossati for his ART ART review:
https://mailarchive.ietf.org/arch/msg/art/EckO_3zF-gnI83Q_HmO5xREursI/ and
thanks to the authors for addressing Thomas' comments.

No other comments from me, just a note: I was wondering if it wouldn't have
made sense to informally reference and discuss in a short paragraph RFC9237 and
its applicability to OAuth given its content - I will accept that it might not
be the case since 9237 is really intended for Ace and IoT but the similarities
made me question it.

Francesca



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 by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.


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