Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Atul Tulshibagwale]

I too have these open questions:
https://mailarchive.ietf.org/arch/msg/oauth/NLj-xnAZ4BtFs9z62OzCro4xxoc/
But I hope they are answered as the draft progresses in the WG.

On Wed, Sep 6, 2023 at 7:08 AM Brian Campbell  wrote:

> I did have a few unanswered comments/questions on the draft
> https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/
> that hopefully can be addressed as it progresses.
>
> On Wed, Sep 6, 2023 at 5:50 AM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> Based on the responses on this thread, we declare the *Protected
>> Resource Metadata* draft adopted as a WG document.
>>
>>
>> Authors,
>>
>> Feel free to submit a WG document at your convenience.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> On Mon, Aug 28, 2023 at 5:28 AM Takahiko Kawasaki 
>> wrote:
>>
>>> I support adoption.
>>>
>>> In the past, when considering the encryption of JWT access tokens, I
>>> learned that the draft regarding the metadata of the resource server had
>>> expired, which was disappointing. For an authorization server to encrypt an
>>> access token with an asymmetric algorithm, it must obtain a public key of
>>> the target resource server, but there was no standardized way. I'm glad to
>>> see the specification has been revived. If it had been revived a bit
>>> earlier, the addition that was made as "client" metadata in the "JWT
>>> Response for OAuth Token Introspection" specification would likely have
>>> been treated as metadata for the "resource server."
>>>
>>> Best Regards,
>>> Takahiko Kawasaki
>>>
>>>
>>> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
>>> rifaat.s.i...@gmail.com> wrote:
>>>
 All,

 This is an official call for adoption for the *Protected Resource
 Metadata* draft:
 https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

 Please, reply on the mailing list and let us know if you are in favor
 of adopting this draft as WG document, by *Sep 6th.*

 Regards,
  Rifaat & Hannes

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

>>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Brian Campbell]

I did have a few unanswered comments/questions on the draft
https://mailarchive.ietf.org/arch/msg/oauth/LA6sqNOV98D7wP44p2Hl6dpSmtg/
that hopefully can be addressed as it progresses.

On Wed, Sep 6, 2023 at 5:50 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Based on the responses on this thread, we declare the *Protected Resource
> Metadata* draft adopted as a WG document.
>
>
> Authors,
>
> Feel free to submit a WG document at your convenience.
>
> Regards,
>  Rifaat & Hannes
>
>
> On Mon, Aug 28, 2023 at 5:28 AM Takahiko Kawasaki 
> wrote:
>
>> I support adoption.
>>
>> In the past, when considering the encryption of JWT access tokens, I
>> learned that the draft regarding the metadata of the resource server had
>> expired, which was disappointing. For an authorization server to encrypt an
>> access token with an asymmetric algorithm, it must obtain a public key of
>> the target resource server, but there was no standardized way. I'm glad to
>> see the specification has been revived. If it had been revived a bit
>> earlier, the addition that was made as "client" metadata in the "JWT
>> Response for OAuth Token Introspection" specification would likely have
>> been treated as metadata for the "resource server."
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>>
>> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *Protected Resource
>>> Metadata* draft:
>>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>>
>>> Please, reply on the mailing list and let us know if you are in favor of
>>> adopting this draft as WG document, by *Sep 6th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Rifaat Shekh-Yusef]

All,

Based on the responses on this thread, we declare the *Protected Resource
Metadata* draft adopted as a WG document.


Authors,

Feel free to submit a WG document at your convenience.

Regards,
 Rifaat & Hannes


On Mon, Aug 28, 2023 at 5:28 AM Takahiko Kawasaki  wrote:

> I support adoption.
>
> In the past, when considering the encryption of JWT access tokens, I
> learned that the draft regarding the metadata of the resource server had
> expired, which was disappointing. For an authorization server to encrypt an
> access token with an asymmetric algorithm, it must obtain a public key of
> the target resource server, but there was no standardized way. I'm glad to
> see the specification has been revived. If it had been revived a bit
> earlier, the addition that was made as "client" metadata in the "JWT
> Response for OAuth Token Introspection" specification would likely have
> been treated as metadata for the "resource server."
>
> Best Regards,
> Takahiko Kawasaki
>
>
> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *Protected Resource
>> Metadata* draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *Sep 6th.*
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Atul Tulshibagwale]

Hi all,
I have a couple of questions about the OPRM draft.


   1. If I have a resource server that has multiple endpoints, each of
   which require different scopes, how should those be handled? For example,
   in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a
   Polling endpoint. The scopes required for these are different. How would
   the client know which scope is to be used with which endpoint?
   2. Does the spec encourage insecure behavior in the caller by requesting
   tokens with scopes that they do not understand? I.e. If an authorization
   server is known to provide valuable tokens with certain scopes, can a
   malicious resource server trick the client into requesting a more powerful
   token, which it then uses to access some other service? Since the consent
   dialog is likely to show two trusted names (i.e. the requesting client and
   the authorization server), the user would be prone to providing consent,
   even if the scope looks unnecessarily permissive.

Thanks,
Atul


On Mon, Aug 28, 2023 at 2:28 AM Takahiko Kawasaki  wrote:

> I support adoption.
>
> In the past, when considering the encryption of JWT access tokens, I
> learned that the draft regarding the metadata of the resource server had
> expired, which was disappointing. For an authorization server to encrypt an
> access token with an asymmetric algorithm, it must obtain a public key of
> the target resource server, but there was no standardized way. I'm glad to
> see the specification has been revived. If it had been revived a bit
> earlier, the addition that was made as "client" metadata in the "JWT
> Response for OAuth Token Introspection" specification would likely have
> been treated as metadata for the "resource server."
>
> Best Regards,
> Takahiko Kawasaki
>
>
> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *Protected Resource
>> Metadata* draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *Sep 6th.*
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Takahiko Kawasaki]

I support adoption.

In the past, when considering the encryption of JWT access tokens, I
learned that the draft regarding the metadata of the resource server had
expired, which was disappointing. For an authorization server to encrypt an
access token with an asymmetric algorithm, it must obtain a public key of
the target resource server, but there was no standardized way. I'm glad to
see the specification has been revived. If it had been revived a bit
earlier, the addition that was made as "client" metadata in the "JWT
Response for OAuth Token Introspection" specification would likely have
been treated as metadata for the "resource server."

Best Regards,
Takahiko Kawasaki


On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Daniel Fett]

+1

Am 28.08.23 um 10:33 schrieb Joseph Heenan:

I support adoption.

Joseph


On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef 
 wrote:


All,

This is an official call for adoption for the *Protected Resource 
Metadata* draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *Sep 6th.*


Regards,
 Rifaat & Hannes

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



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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Joseph Heenan]

I support adoption.

Joseph


> On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef  wrote:
> 
> All,
> 
> This is an official call for adoption for the Protected Resource Metadata 
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
> 
> Please, reply on the mailing list and let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Neil Madden]

Right. It’s worth noting that many endpoints already publish similar metadata via OpenAPI (Swagger) API descriptions.NeilOn 27 Aug 2023, at 19:42, Dick Hardt  wrote:For many resources, the information is already disclosed. What is excessive to you might be crucial to others -- and my use case, the disclosure is crucial. Extrapolating your basis for objecting, that another endpoint provides additional attack surface, we would not do ANY new endpoints or functionality since they would all provide more attack surface.On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh  wrote:Hi Dick,My previous emails do not even obliquely refer to security by obscurity. It is about design patterns and excessive information disclosure.RegardsJaimandeep Singh On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:Jaimandeep: Do I understand your objection to adoption is that providing a resource discovery endpoint increases the attack surface as an attacker gains knowledge about the resource?If I understand that correctly, then you are suggesting security through obscurity.As mentioned by Aaron, there is no requirement for a resource to support the resource metadata, and the metadata itself could be protected. Practically though, I believe the argument that security is improved by not having a resource discovery endpoint is false. Most resources have publicly available documentation which will contain the same information, and while the docs are not necessarily machine readable, LLMs can make it pretty accessible. Even if you wanted to keep it secret, if applications that use the resource are readily available, how the applications interact with the resource can be discerned through reverse engineering. I think that a security consideration calling out that a malicious actor more readily has access to the protected resource metadata is an adequate response.For my use case, the protected resource metadata is required for the functionality I plan to implement. The AS has no prior knowledge about the protected resource, and when a request is made, the AS learns about the PR and presents the user with an experience based on the metadata for the user to make a decision to grant access. /DickOn Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:Hi Aaron,Thx for your suggestions. I have reviewed the recordings and I would suggest following:1. Design Consideration: The two components of the OAuth 2.0 ecosystem authorization server (step 1) and protected resource server (step 2) may appear independent, but from systems perspective there is a linear dependency between them. Directly engaging with step 2, even in a limited capacity, threatens the established sequence and poses substantial security and architectural implications.2. Information Disclosure: Say I have my HIPPA record stored on a protected resource server, I don't want any app to even know that I have such a resource available with a protected resource server in the first place. The concept of exposing the mere existence of such data raises a glaring concern. Looking at Google, it has a fine-grained authorization strategy that meticulously limits access for its RESTRICTED scopes only to apps that meet certain security benchmarks. Once, the malicious apps come to know of the prized data at the resource server, it will lead to targeted phishing attacks, as was highlighted during the 117 meeting, underscoring the fragility of this approach.3. The Imperative of Gradation and Minimal Exposure: Even if we have to go down this path, there is a definite need to mitigate the perils of overexposure. Instead we can look at gradation strategy, wherein the scopes could be categorized into levels, spanning from generic (Level 0) to tightly controlled (Level 5) access. There is no requirement of secondary URI in this appch. For instance, the sensitive scopes like level 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no need to divulge if a particular resource is present or not and not even the address of the authorization server.ThanksJaimandeep SinghOn Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote:Hi Jaimandeep,As with many OAuth extensions, this is not obligatory to implement unless you need the functionality it provides. Many of the concerns you mention are referenced in the security considerations section of the draft already, and we would of course be happy to further expand that section as appropriate. As we presented during the last two IETF meetings, there are many use cases that would benefit from this draft that currently don't have an interoperable solution. I would suggest you review those presentation recordings so better understand the use cases.AaronOn Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:I do not support the adoption because of following:1. Increased Attack Surface and Information Disclosure: The 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Dick Hardt]

For many resources, the information is already disclosed. What is excessive
to you might be crucial to others -- and my use case, the disclosure is
crucial.

Extrapolating your basis for objecting, that another endpoint provides
additional attack surface, we would not do ANY new endpoints or
functionality since they would all provide more attack surface.

On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Hi Dick,
>
> My previous emails do not even obliquely refer to security by obscurity.
> It is about design patterns and excessive information disclosure.
>
> Regards
> Jaimandeep Singh
>
> On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:
>
>> Jaimandeep: Do I understand your objection to adoption is that providing
>> a resource discovery endpoint increases the attack surface as an
>> attacker gains knowledge about the resource?
>>
>> If I understand that correctly, then you are suggesting security through
>> obscurity.
>>
>> As mentioned by Aaron, there is no requirement for a resource to support
>> the resource metadata, and the metadata itself could be protected.
>>
>> Practically though, I believe the argument that security is improved by
>> not having a resource discovery endpoint is false. Most resources have
>> publicly available documentation which will contain the same information,
>> and while the docs are not necessarily machine readable, LLMs can make it
>> pretty accessible.
>>
>> Even if you wanted to keep it secret, if applications that use the
>> resource are readily available, how the applications interact with the
>> resource can be discerned through reverse engineering.
>> I think that a security consideration calling out that a malicious actor
>> more readily has access to the protected resource metadata is an adequate
>> response.
>>
>> For my use case, the protected resource metadata is required for the
>> functionality I plan to implement. The AS has no prior knowledge about the
>> protected resource, and when a request is made, the AS learns about the PR
>> and presents the user with an experience based on the metadata for the user
>> to make a decision to grant access.
>>
>> /Dick
>>
>>
>>
>> On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh > 40nfsu.ac...@dmarc.ietf.org> wrote:
>>
>>> Hi Aaron,
>>>
>>> Thx for your suggestions. I have reviewed the recordings and I would
>>> suggest following:
>>>
>>> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
>>> authorization server (step 1) and protected resource server (step 2) may
>>> appear independent, but from systems perspective there is a linear
>>> dependency between them. Directly engaging with step 2, even in a limited
>>> capacity, threatens the established sequence and poses substantial security
>>> and architectural implications.
>>>
>>> 2. Information Disclosure: Say I have my HIPPA record stored on a
>>> protected resource server, I don't want any app to even know that I have
>>> such a resource available with a protected resource server in the first
>>> place. The concept of exposing the mere existence of such data raises a
>>> glaring concern. Looking at Google, it has a fine-grained authorization
>>> strategy that meticulously limits access for its RESTRICTED scopes only to
>>> apps that meet certain security benchmarks. Once, the malicious apps come
>>> to know of the prized data at the resource server, it will lead to targeted
>>> phishing attacks, as was highlighted during the 117 meeting, underscoring
>>> the fragility of this approach.
>>>
>>> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to
>>> go down this path, there is a definite need to mitigate the perils of
>>> overexposure. Instead we can look at gradation strategy, wherein the scopes
>>> could be categorized into levels, spanning from generic (Level 0) to
>>> tightly controlled (Level 5) access. There is no requirement of
>>> secondary URI in this appch. For instance, the sensitive scopes like level
>>> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
>>> need to divulge if a particular resource is present or not and not even the
>>> address of the authorization server.
>>>
>>> Thanks
>>> Jaimandeep Singh
>>>
>>>
>>> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki >> 40parecki@dmarc.ietf.org> wrote:
>>>
 Hi Jaimandeep,

 As with many OAuth extensions, this is not obligatory to implement
 unless you need the functionality it provides. Many of the concerns you
 mention are referenced in the security considerations section of the draft
 already, and we would of course be happy to further expand that section as
 appropriate.

 As we presented during the last two IETF meetings, there are many use
 cases that would benefit from this draft that currently don't have an
 interoperable solution. I would suggest you review those presentation
 recordings so better understand the use cases.

 Aaron

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Jaimandeep Singh]

Hi Dick,

My previous emails do not even obliquely refer to security by obscurity. It
is about design patterns and excessive information disclosure.

Regards
Jaimandeep Singh

On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:

> Jaimandeep: Do I understand your objection to adoption is that providing a
> resource discovery endpoint increases the attack surface as an
> attacker gains knowledge about the resource?
>
> If I understand that correctly, then you are suggesting security through
> obscurity.
>
> As mentioned by Aaron, there is no requirement for a resource to support
> the resource metadata, and the metadata itself could be protected.
>
> Practically though, I believe the argument that security is improved by
> not having a resource discovery endpoint is false. Most resources have
> publicly available documentation which will contain the same information,
> and while the docs are not necessarily machine readable, LLMs can make it
> pretty accessible.
>
> Even if you wanted to keep it secret, if applications that use the
> resource are readily available, how the applications interact with the
> resource can be discerned through reverse engineering.
> I think that a security consideration calling out that a malicious actor
> more readily has access to the protected resource metadata is an adequate
> response.
>
> For my use case, the protected resource metadata is required for the
> functionality I plan to implement. The AS has no prior knowledge about the
> protected resource, and when a request is made, the AS learns about the PR
> and presents the user with an experience based on the metadata for the user
> to make a decision to grant access.
>
> /Dick
>
>
>
> On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Hi Aaron,
>>
>> Thx for your suggestions. I have reviewed the recordings and I would
>> suggest following:
>>
>> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
>> authorization server (step 1) and protected resource server (step 2) may
>> appear independent, but from systems perspective there is a linear
>> dependency between them. Directly engaging with step 2, even in a limited
>> capacity, threatens the established sequence and poses substantial security
>> and architectural implications.
>>
>> 2. Information Disclosure: Say I have my HIPPA record stored on a
>> protected resource server, I don't want any app to even know that I have
>> such a resource available with a protected resource server in the first
>> place. The concept of exposing the mere existence of such data raises a
>> glaring concern. Looking at Google, it has a fine-grained authorization
>> strategy that meticulously limits access for its RESTRICTED scopes only to
>> apps that meet certain security benchmarks. Once, the malicious apps come
>> to know of the prized data at the resource server, it will lead to targeted
>> phishing attacks, as was highlighted during the 117 meeting, underscoring
>> the fragility of this approach.
>>
>> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to
>> go down this path, there is a definite need to mitigate the perils of
>> overexposure. Instead we can look at gradation strategy, wherein the scopes
>> could be categorized into levels, spanning from generic (Level 0) to
>> tightly controlled (Level 5) access. There is no requirement of
>> secondary URI in this appch. For instance, the sensitive scopes like level
>> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
>> need to divulge if a particular resource is present or not and not even the
>> address of the authorization server.
>>
>> Thanks
>> Jaimandeep Singh
>>
>>
>> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote:
>>
>>> Hi Jaimandeep,
>>>
>>> As with many OAuth extensions, this is not obligatory to implement
>>> unless you need the functionality it provides. Many of the concerns you
>>> mention are referenced in the security considerations section of the draft
>>> already, and we would of course be happy to further expand that section as
>>> appropriate.
>>>
>>> As we presented during the last two IETF meetings, there are many use
>>> cases that would benefit from this draft that currently don't have an
>>> interoperable solution. I would suggest you review those presentation
>>> recordings so better understand the use cases.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh >> 40nfsu.ac...@dmarc.ietf.org> wrote:
>>>
 I do not support the adoption because of following:

 1. Increased Attack Surface and Information Disclosure: The proposed
 draft inherently expands the attack surface by allowing the retrieval of
 detailed information about the protected resources held with a
 particular resource server, as outlined in section 3.1. We are
 inadvertently exposing the resources supported by the protected resource
 server. The 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Tom Jones]

The security reason for exclusion of error codes and other information is
that the data helps the attacker subvert the app. I continue my attempt to
avoid helping the attacker.

thx ..Tom (mobile)

On Sat, Aug 26, 2023, 7:58 AM Dick Hardt  wrote:

> Jaimandeep: Do I understand your objection to adoption is that providing a
> resource discovery endpoint increases the attack surface as an
> attacker gains knowledge about the resource?
>
> If I understand that correctly, then you are suggesting security through
> obscurity.
>
> As mentioned by Aaron, there is no requirement for a resource to support
> the resource metadata, and the metadata itself could be protected.
>
> Practically though, I believe the argument that security is improved by
> not having a resource discovery endpoint is false. Most resources have
> publicly available documentation which will contain the same information,
> and while the docs are not necessarily machine readable, LLMs can make it
> pretty accessible.
>
> Even if you wanted to keep it secret, if applications that use the
> resource are readily available, how the applications interact with the
> resource can be discerned through reverse engineering.
> I think that a security consideration calling out that a malicious actor
> more readily has access to the protected resource metadata is an adequate
> response.
>
> For my use case, the protected resource metadata is required for the
> functionality I plan to implement. The AS has no prior knowledge about the
> protected resource, and when a request is made, the AS learns about the PR
> and presents the user with an experience based on the metadata for the user
> to make a decision to grant access.
>
> /Dick
>
>
>
> On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> Hi Aaron,
>>
>> Thx for your suggestions. I have reviewed the recordings and I would
>> suggest following:
>>
>> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
>> authorization server (step 1) and protected resource server (step 2) may
>> appear independent, but from systems perspective there is a linear
>> dependency between them. Directly engaging with step 2, even in a limited
>> capacity, threatens the established sequence and poses substantial security
>> and architectural implications.
>>
>> 2. Information Disclosure: Say I have my HIPPA record stored on a
>> protected resource server, I don't want any app to even know that I have
>> such a resource available with a protected resource server in the first
>> place. The concept of exposing the mere existence of such data raises a
>> glaring concern. Looking at Google, it has a fine-grained authorization
>> strategy that meticulously limits access for its RESTRICTED scopes only to
>> apps that meet certain security benchmarks. Once, the malicious apps come
>> to know of the prized data at the resource server, it will lead to targeted
>> phishing attacks, as was highlighted during the 117 meeting, underscoring
>> the fragility of this approach.
>>
>> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to
>> go down this path, there is a definite need to mitigate the perils of
>> overexposure. Instead we can look at gradation strategy, wherein the scopes
>> could be categorized into levels, spanning from generic (Level 0) to
>> tightly controlled (Level 5) access. There is no requirement of
>> secondary URI in this appch. For instance, the sensitive scopes like level
>> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
>> need to divulge if a particular resource is present or not and not even the
>> address of the authorization server.
>>
>> Thanks
>> Jaimandeep Singh
>>
>>
>> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote:
>>
>>> Hi Jaimandeep,
>>>
>>> As with many OAuth extensions, this is not obligatory to implement
>>> unless you need the functionality it provides. Many of the concerns you
>>> mention are referenced in the security considerations section of the draft
>>> already, and we would of course be happy to further expand that section as
>>> appropriate.
>>>
>>> As we presented during the last two IETF meetings, there are many use
>>> cases that would benefit from this draft that currently don't have an
>>> interoperable solution. I would suggest you review those presentation
>>> recordings so better understand the use cases.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh >> 40nfsu.ac...@dmarc.ietf.org> wrote:
>>>
 I do not support the adoption because of following:

 1. Increased Attack Surface and Information Disclosure: The proposed
 draft inherently expands the attack surface by allowing the retrieval of
 detailed information about the protected resources held with a
 particular resource server, as outlined in section 3.1. We are
 inadvertently exposing the resources supported by the protected 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Dick Hardt]

Jaimandeep: Do I understand your objection to adoption is that providing a
resource discovery endpoint increases the attack surface as an
attacker gains knowledge about the resource?

If I understand that correctly, then you are suggesting security through
obscurity.

As mentioned by Aaron, there is no requirement for a resource to support
the resource metadata, and the metadata itself could be protected.

Practically though, I believe the argument that security is improved by not
having a resource discovery endpoint is false. Most resources have publicly
available documentation which will contain the same information, and while
the docs are not necessarily machine readable, LLMs can make it pretty
accessible.

Even if you wanted to keep it secret, if applications that use the resource
are readily available, how the applications interact with the resource can
be discerned through reverse engineering.
I think that a security consideration calling out that a malicious actor
more readily has access to the protected resource metadata is an adequate
response.

For my use case, the protected resource metadata is required for the
functionality I plan to implement. The AS has no prior knowledge about the
protected resource, and when a request is made, the AS learns about the PR
and presents the user with an experience based on the metadata for the user
to make a decision to grant access.

/Dick



On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh  wrote:

> Hi Aaron,
>
> Thx for your suggestions. I have reviewed the recordings and I would
> suggest following:
>
> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
> authorization server (step 1) and protected resource server (step 2) may
> appear independent, but from systems perspective there is a linear
> dependency between them. Directly engaging with step 2, even in a limited
> capacity, threatens the established sequence and poses substantial security
> and architectural implications.
>
> 2. Information Disclosure: Say I have my HIPPA record stored on a
> protected resource server, I don't want any app to even know that I have
> such a resource available with a protected resource server in the first
> place. The concept of exposing the mere existence of such data raises a
> glaring concern. Looking at Google, it has a fine-grained authorization
> strategy that meticulously limits access for its RESTRICTED scopes only to
> apps that meet certain security benchmarks. Once, the malicious apps come
> to know of the prized data at the resource server, it will lead to targeted
> phishing attacks, as was highlighted during the 117 meeting, underscoring
> the fragility of this approach.
>
> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to go
> down this path, there is a definite need to mitigate the perils of
> overexposure. Instead we can look at gradation strategy, wherein the scopes
> could be categorized into levels, spanning from generic (Level 0) to
> tightly controlled (Level 5) access. There is no requirement of
> secondary URI in this appch. For instance, the sensitive scopes like level
> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
> need to divulge if a particular resource is present or not and not even the
> address of the authorization server.
>
> Thanks
> Jaimandeep Singh
>
>
> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki  40parecki@dmarc.ietf.org> wrote:
>
>> Hi Jaimandeep,
>>
>> As with many OAuth extensions, this is not obligatory to implement unless
>> you need the functionality it provides. Many of the concerns you mention
>> are referenced in the security considerations section of the draft already,
>> and we would of course be happy to further expand that section as
>> appropriate.
>>
>> As we presented during the last two IETF meetings, there are many use
>> cases that would benefit from this draft that currently don't have an
>> interoperable solution. I would suggest you review those presentation
>> recordings so better understand the use cases.
>>
>> Aaron
>>
>>
>>
>>
>> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh > 40nfsu.ac...@dmarc.ietf.org> wrote:
>>
>>> I do not support the adoption because of following:
>>>
>>> 1. Increased Attack Surface and Information Disclosure: The proposed
>>> draft inherently expands the attack surface by allowing the retrieval of
>>> detailed information about the protected resources held with a
>>> particular resource server, as outlined in section 3.1. We are
>>> inadvertently exposing the resources supported by the protected resource
>>> server. The secondary URIs which correspond to each of the protected
>>> resources further expands the potential attack vectors. To illustrate, if a
>>> protected resource server supports resources from 1 to 10, and a client
>>> requests metadata for all these resources, it leads to 11 requests (1 +
>>> 10). This exposes a total of 11 URIs to potential attackers with
>>> information 

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Jaimandeep Singh]

Hi Aaron,

Thx for your suggestions. I have reviewed the recordings and I would
suggest following:

1. Design Consideration: The two components of the OAuth 2.0 ecosystem
authorization server (step 1) and protected resource server (step 2) may
appear independent, but from systems perspective there is a linear
dependency between them. Directly engaging with step 2, even in a limited
capacity, threatens the established sequence and poses substantial security
and architectural implications.

2. Information Disclosure: Say I have my HIPPA record stored on a protected
resource server, I don't want any app to even know that I have such a
resource available with a protected resource server in the first place. The
concept of exposing the mere existence of such data raises a glaring
concern. Looking at Google, it has a fine-grained authorization strategy
that meticulously limits access for its RESTRICTED scopes only to apps that
meet certain security benchmarks. Once, the malicious apps come to know of
the prized data at the resource server, it will lead to targeted phishing
attacks, as was highlighted during the 117 meeting, underscoring the
fragility of this approach.

3. The Imperative of Gradation and Minimal Exposure: Even if we have to go
down this path, there is a definite need to mitigate the perils of
overexposure. Instead we can look at gradation strategy, wherein the scopes
could be categorized into levels, spanning from generic (Level 0) to
tightly controlled (Level 5) access. There is no requirement of
secondary URI in this appch. For instance, the sensitive scopes like level
3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
need to divulge if a particular resource is present or not and not even the
address of the authorization server.

Thanks
Jaimandeep Singh


On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki  wrote:

> Hi Jaimandeep,
>
> As with many OAuth extensions, this is not obligatory to implement unless
> you need the functionality it provides. Many of the concerns you mention
> are referenced in the security considerations section of the draft already,
> and we would of course be happy to further expand that section as
> appropriate.
>
> As we presented during the last two IETF meetings, there are many use
> cases that would benefit from this draft that currently don't have an
> interoperable solution. I would suggest you review those presentation
> recordings so better understand the use cases.
>
> Aaron
>
>
>
>
> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh  40nfsu.ac...@dmarc.ietf.org> wrote:
>
>> I do not support the adoption because of following:
>>
>> 1. Increased Attack Surface and Information Disclosure: The proposed
>> draft inherently expands the attack surface by allowing the retrieval of
>> detailed information about the protected resources held with a
>> particular resource server, as outlined in section 3.1. We are
>> inadvertently exposing the resources supported by the protected resource
>> server. The secondary URIs which correspond to each of the protected
>> resources further expands the potential attack vectors. To illustrate, if a
>> protected resource server supports resources from 1 to 10, and a client
>> requests metadata for all these resources, it leads to 11 requests (1 +
>> 10). This exposes a total of 11 URIs to potential attackers with
>> information disclosure.
>>
>> 2. Lack of Client Verification and Potential DDoS Vulnerability: There is
>> absence of client application verification before it accesses the APIs.
>> This can lead to the possibility of malicious client applications
>> initiating Distributed Denial of Service (DDoS) attacks.
>>
>> 3. Impact on Processing Time due to Multiple Resources: The need to
>> wildcard match/support numerous secondary URIs based on the number of
>> protected resources could lead to increased processing time.
>>
>> 4. Strengthening the Existing System with Adequate Error Codes: Our
>> existing OAuth RFC, can handle this issue gracefully by incorporating error
>> codes. This ensures that, at the very least, access tokens are verified
>> before any specific information is disclosed.
>>
>> Thanks
>> Jaimandeep Singh
>>
>> On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is an official call for adoption for the *Protected Resource
>>> Metadata* draft:
>>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>>
>>> Please, reply on the mailing list and let us know if you are in favor of
>>> adopting this draft as WG document, by *Sep 6th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>> Regards and Best Wishes
>> Jaimandeep Singh
>> LinkedIn 
>> ___
>> OAuth mailing list

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Aaron Parecki]

Hi Jaimandeep,

As with many OAuth extensions, this is not obligatory to implement unless
you need the functionality it provides. Many of the concerns you mention
are referenced in the security considerations section of the draft already,
and we would of course be happy to further expand that section as
appropriate.

As we presented during the last two IETF meetings, there are many use cases
that would benefit from this draft that currently don't have an
interoperable solution. I would suggest you review those presentation
recordings so better understand the use cases.

Aaron




On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh  wrote:

> I do not support the adoption because of following:
>
> 1. Increased Attack Surface and Information Disclosure: The proposed draft
> inherently expands the attack surface by allowing the retrieval of detailed
> information about the protected resources held with a particular resource
> server, as outlined in section 3.1. We are inadvertently exposing the
> resources supported by the protected resource server. The secondary URIs
> which correspond to each of the protected resources further expands the
> potential attack vectors. To illustrate, if a protected resource server
> supports resources from 1 to 10, and a client requests metadata for all
> these resources, it leads to 11 requests (1 + 10). This exposes a total
> of 11 URIs to potential attackers with information disclosure.
>
> 2. Lack of Client Verification and Potential DDoS Vulnerability: There is
> absence of client application verification before it accesses the APIs.
> This can lead to the possibility of malicious client applications
> initiating Distributed Denial of Service (DDoS) attacks.
>
> 3. Impact on Processing Time due to Multiple Resources: The need to
> wildcard match/support numerous secondary URIs based on the number of
> protected resources could lead to increased processing time.
>
> 4. Strengthening the Existing System with Adequate Error Codes: Our
> existing OAuth RFC, can handle this issue gracefully by incorporating error
> codes. This ensures that, at the very least, access tokens are verified
> before any specific information is disclosed.
>
> Thanks
> Jaimandeep Singh
>
> On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *Protected Resource
>> Metadata* draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *Sep 6th.*
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Michael Schwartz]

I support adoption


On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef 
 wrote:


All,

This is an official call for adoption for the Protected Resource 
Metadata draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by Sep 6th.


Regards,
 Rifaat & Hannes



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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Jaimandeep Singh]

I do not support the adoption because of following:

1. Increased Attack Surface and Information Disclosure: The proposed draft
inherently expands the attack surface by allowing the retrieval of detailed
information about the protected resources held with a particular resource
server, as outlined in section 3.1. We are inadvertently exposing the
resources supported by the protected resource server. The secondary URIs
which correspond to each of the protected resources further expands the
potential attack vectors. To illustrate, if a protected resource server
supports resources from 1 to 10, and a client requests metadata for all
these resources, it leads to 11 requests (1 + 10). This exposes a total of
11 URIs to potential attackers with information disclosure.

2. Lack of Client Verification and Potential DDoS Vulnerability: There is
absence of client application verification before it accesses the APIs.
This can lead to the possibility of malicious client applications
initiating Distributed Denial of Service (DDoS) attacks.

3. Impact on Processing Time due to Multiple Resources: The need to
wildcard match/support numerous secondary URIs based on the number of
protected resources could lead to increased processing time.

4. Strengthening the Existing System with Adequate Error Codes: Our
existing OAuth RFC, can handle this issue gracefully by incorporating error
codes. This ensures that, at the very least, access tokens are verified
before any specific information is disclosed.

Thanks
Jaimandeep Singh

On Thu, Aug 24, 2023 at 12:32 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Regards and Best Wishes
Jaimandeep Singh
LinkedIn 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Neil Madden]

I support adoption. 

> On 23 Aug 2023, at 20:02, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> This is an official call for adoption for the Protected Resource Metadata 
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
> 
> Please, reply on the mailing list and let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Oliver Terbu]

I support adoption

On Fri, Aug 25, 2023 at 5:09 PM John Bradley  wrote:

> I support addoption
>
> On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[John Bradley]

I support addoption

> On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef  
> wrote:
> 
> All,
> 
> This is an official call for adoption for the Protected Resource Metadata 
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
> 
> Please, reply on the mailing list and let us know if you are in favor of 
> adopting this draft as WG document, by Sep 6th.
> 
> Regards,
>  Rifaat & Hannes
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Leif Johansson]

I support adoption too24 aug. 2023 kl. 08:31 skrev Vladimir Dzhuvinov :
  

  
  
I support adoption.

Vladimir Dzhuvinov
On 23/08/2023 20:01, Rifaat Shekh-Yusef
  wrote:


  
  
All,
  
  This is an official call for adoption for the Protected
Resource Metadata draft:
  https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
  
  Please, reply on the mailing list and let us know if you are
  in favor of adopting this draft as WG document, by Sep
6th.
  
  Regards,
   Rifaat & Hannes
  

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


  

___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Vladimir Dzhuvinov]

I support adoption.

Vladimir Dzhuvinov

On 23/08/2023 20:01, Rifaat Shekh-Yusef wrote:

All,

This is an official call for adoption for the *Protected Resource 
Metadata* draft:

https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor 
of adopting this draft as WG document, by *Sep 6th.*


Regards,
 Rifaat & Hannes


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

smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[David Waite]

I support adoption

> On Aug 23, 2023, at 11:44 PM, Aaron Parecki 
>  wrote:
> 
> I support adoption.
> 
> Aaron
> 
> 
> On Wed, Aug 23, 2023 at 8:02 PM Rifaat Shekh-Yusef  > wrote:
>> All,
>> 
>> This is an official call for adoption for the Protected Resource Metadata 
>> draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>> 
>> Please, reply on the mailing list and let us know if you are in favor of 
>> adopting this draft as WG document, by Sep 6th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> --
> ---
> Aaron Parecki
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Amir Sharif]

I support adoption of this draft.


On Thu, 24 Aug 2023 at 06:41, Tobias Looker  wrote:

> I support adoption of this draft.
>
>
>
> Thanks,
>
> [image: MATTR website] <https://mattr.global/>
>
>
>
> *Tobias Looker*
>
> MATTR
>
> +64 273 780 461
> tobias.looker@mattr.global 
>
> [image: MATTR website] <https://mattr.global/>
>
> [image: MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal>
>
> [image: MATTR on Twitter] <https://twitter.com/mattrglobal>
>
> [image: MATTR on Github] <https://github.com/mattrglobal>
>
>
> 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: *OAuth  on behalf of Heather Flanagan <
> h...@sphericalcowconsulting.com>
> *Date: *Thursday, 24 August 2023 at 10:51 AM
> *To: *Steinar Noem , oauth 
> *Subject: *Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
>
> 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.
>
>
>
> Hi all,
>
>
>
> I have to chime in on this one. +1 to supporting it for adoption!
>
>
>
> -Heather
>
>
>
> On Aug 23, 2023, at 3:46 PM, Steinar Noem  wrote:
>
>
>
> I support adoption
>
>
>
> ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com>:
>
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vennlig hilsen
>
>
>
> Steinar Noem
>
> Partner Udelt AS
>
> Systemutvikler
>
>
>
> | stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
*Amir Sharif*
*Researcher*
*Security and Trust Research Unit*
*Cybersecurity Center*
*Fondazione Bruno Kessler, Trento, Italy*
personal page:https://st.fbk.eu/people/amir-sharif
FBK web: www.fbk.eu
Security  web: st.fbk.eu

-- 
--
Le informazioni contenute nella presente comunicazione sono di natura 
privata e come tali sono da considerarsi riservate ed indirizzate 
esclusivamente ai destinatari indicati e per le finalità strettamente 
legate al relativo contenuto. Se avete ricevuto questo messaggio per 
errore, vi preghiamo di eliminarlo e di inviare una comunicazione 
all’indirizzo e-mail del mittente.

--
The information transmitted is 
intended only for the person or entity to which it is addressed and may 
contain confidential and/or privileged material. If you received this in 
error, please contact the sender and delete the material.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Aaron Parecki]

I support adoption.

Aaron


On Wed, Aug 23, 2023 at 8:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
---
Aaron Parecki
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Tobias Looker]

I support adoption of this draft.

Thanks,
[MATTR website]<https://mattr.global/>

Tobias Looker
MATTR
+64 273 780 461
tobias.looker@mattr.global<mailto:first.last@mattr.global>
[MATTR website]<https://mattr.global/>
[MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal>
[MATTR on Twitter]<https://twitter.com/mattrglobal>
[MATTR on Github]<https://github.com/mattrglobal>

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: OAuth  on behalf of Heather Flanagan 

Date: Thursday, 24 August 2023 at 10:51 AM
To: Steinar Noem , oauth 
Subject: Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
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.

Hi all,

I have to chime in on this one. +1 to supporting it for adoption!

-Heather


On Aug 23, 2023, at 3:46 PM, Steinar Noem  wrote:

I support adoption

ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>>:
All,

This is an official call for adoption for the Protected Resource Metadata draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by Sep 6th.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no<mailto:stei...@udelt.no> | 
h...@udelt.no<mailto:h...@udelt.no>  | +47 955 21 620 | 
www.udelt.no<http://www.udelt.no/> |

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Heather Flanagan]

Hi all,

I have to chime in on this one. +1 to supporting it for adoption!

-Heather

> On Aug 23, 2023, at 3:46 PM, Steinar Noem  wrote:
> 
> I support adoption
> 
> ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef 
> mailto:rifaat.s.i...@gmail.com>>:
>> All,
>> 
>> This is an official call for adoption for the Protected Resource Metadata 
>> draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>> 
>> Please, reply on the mailing list and let us know if you are in favor of 
>> adopting this draft as WG document, by Sep 6th.
>> 
>> Regards,
>>  Rifaat & Hannes
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> Vennlig hilsen
> 
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>  
> | stei...@udelt.no  | h...@udelt.no 
>   | +47 955 21 620 <> | www.udelt.no 
>  | 

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Steinar Noem]

I support adoption

ons. 23. aug. 2023 kl. 20:03 skrev Rifaat Shekh-Yusef <
rifaat.s.i...@gmail.com>:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler

| stei...@udelt.no | h...@udelt.no  | +47 955 21 620 | www.udelt.no |
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Nicole Roy]

I support adoption.

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Michael Prorock]

I support adoption

Mike Prorock
CTO - mesur.io

On Wed, Aug 23, 2023, 16:21 Giuseppe De Marco  wrote:

> Hi,
> I support the adoption.
>
> Il mer 23 ago 2023, 21:02 Rifaat Shekh-Yusef  ha
> scritto:
>
>> All,
>>
>> This is an official call for adoption for the *Protected Resource
>> Metadata* draft:
>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *Sep 6th.*
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Giuseppe De Marco]

Hi,
I support the adoption.

Il mer 23 ago 2023, 21:02 Rifaat Shekh-Yusef  ha
scritto:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Pieter Kasselman]

I support adoption

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, August 23, 2023 8:02 PM
To: oauth 
Subject: [OAUTH-WG] Call for adoption - Protected Resource Metadata

All,

This is an official call for adoption for the Protected Resource Metadata draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by Sep 6th.

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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Orie Steele]

I support adoption.

On Wed, Aug 23, 2023, 5:06 PM Michael Jones 
wrote:

> I support adoption.
>
> -- Mike
>
>
> --
> *From:* OAuth  on behalf of Dick Hardt <
> dick.ha...@gmail.com>
> *Sent:* Wednesday, August 23, 2023 8:09:46 PM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
>
> I support adoption.
>
> On Wed, Aug 23, 2023 at 12:02 PM Rifaat Shekh-Yusef <
> rifaat.s.i...@gmail.com> wrote:
>
> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Michael Jones]

I support adoption.

-- Mike



From: OAuth  on behalf of Dick Hardt 

Sent: Wednesday, August 23, 2023 8:09:46 PM
To: Rifaat Shekh-Yusef 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support adoption.

On Wed, Aug 23, 2023 at 12:02 PM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is an official call for adoption for the Protected Resource Metadata draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor of 
adopting this draft as WG document, by Sep 6th.

Regards,
 Rifaat & Hannes

___
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

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Dick Hardt]

I support adoption.

On Wed, Aug 23, 2023 at 12:02 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Protected Resource
> Metadata* draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *Sep 6th.*
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Call for adoption - Protected Resource Metadata

[Rifaat Shekh-Yusef]

All,

This is an official call for adoption for the *Protected Resource Metadata*
draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/

Please, reply on the mailing list and let us know if you are in favor of
adopting this draft as WG document, by *Sep 6th.*

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