[OAUTH-WG] Transaction Token Service deployment models

[George Fletcher]

I’ve opened a new issue to discuss Transaction Token Service deployment
models:

https://github.com/oauth-wg/oauth-transaction-tokens/issues/96


I’ve added one comment. Please consider adding different deployments models
(or comment on the one I added) as this will help determine if more text is
needed in the specification.


Thanks,

George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Hi Kai,

I see your point. I agree that the subject_token may not need to be signed
depending on the deployment. This was true when we made the proposal that
the subject_token could be a simple string (e.g. email address). If the
subject_token is signed, the TTS could verify that the subject_token was
issued by the same client making the request. However, that might not
always be valid either:)

Thanks,
George

On Tue, Apr 23, 2024 at 11:25 AM Kai Lehmann  wrote:

> Hi George,
>
>
>
> The Token Exchange request ist requiring client authentication. A TTS
> needs to trust this authenticated client to provide a correct subject to
> some extend. This is also the case if the client would provide a
> self-signed JWT containing the subject instead. Using a JWT as a subject
> token has definitely some benefits as the format/content can be specified,
> but I don’t see how signing the JWT would make the trust by the TTS towards
> the client unnecessary.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of George Fletcher
> 
> *Date: *Monday, 22. April 2024 at 17:50
> *To: *Kai Lehmann 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Kai,
>
>
>
> How would the TTS trust the incoming "subject" value if not signed? Do you
> have something in mind?
>
>
>
> Thanks,
>
> George
>
>
>
> On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> Sorry for replying to this so late to this thread. Although self-signed
> JWTs may help to fill the subject_token for Token Exchange, I think it can
> be a burden for the Workload presenting the Self signed JWT as well as for
> the Txn Token Service to validate that token. It would require the Workload
> to do generate and maintain proper signing key material – including
> rotating those keys on a regular basis as well as making them available to
> the Txn Token Service. Workloads may not have the capability to serve a
> JKWS file as they are purely operating in a backend environment (batch
> processes).
>
>
>
> As this discussion is more or less already concluded, I hope that the spec
> can at least allow alternatives.
>
>
>
> BR,
>
> Kai
>
>
>
>
>
> *From: *George Fletcher 
> *Date: *Friday, 12. April 2024 at 19:53
> *To: *Atul Tulshibagwale 
> *Cc: *Brian Campbell , Kai Lehmann <
> kai.lehm...@1und1.de>, Dmitry Telegin , oauth <
> oauth@ietf.org>
> *Subject: *Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Atul has submitted this PR to address this issue.
>
> https://github.com/oauth-wg/oauth-transaction-tokens/pull/90
> <https://urldefense.com/v3/__https:/github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>
>
>
>
> On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:
>
> Thanks all, for your input. We discussed alternatives on a call last week
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
>
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
> One potential benefit of keeping the use of Token Exchange is that some AS
> products/implementations have built a fair amount of configurability and
> extensibility into their Token Exchange support, which might allow for
> existing systems to be set up to do Transaction Tokens. Whereas a new
> endpoint or new grant type are more likely to require code changes to the
> core AS. Obviously this isn't universally true but something to consider
> nonetheless.
>
>
>
> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> that is my thought as well. It does not necessarily be a Token Exchange
> profile, but the Token endpoint makes sense as Tokens are issued. Defining
> a specific Token grant with the necessary input parameters would fit nicely.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of Dmitry Telegin
> 
> *Date: *Friday, 5. April 2024 at 00:41
> *To: *Atul Tulshibagwale 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
> incoming token
>
>
>
> Hello Atul,
>
>
>
> As an alternative to Token Exchange and separate (

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Kai,

How would the TTS trust the incoming "subject" value if not signed? Do you
have something in mind?

Thanks,
George

On Tue, Apr 16, 2024 at 3:46 AM Kai Lehmann  wrote:

> Hi,
>
>
>
> Sorry for replying to this so late to this thread. Although self-signed
> JWTs may help to fill the subject_token for Token Exchange, I think it can
> be a burden for the Workload presenting the Self signed JWT as well as for
> the Txn Token Service to validate that token. It would require the Workload
> to do generate and maintain proper signing key material – including
> rotating those keys on a regular basis as well as making them available to
> the Txn Token Service. Workloads may not have the capability to serve a
> JKWS file as they are purely operating in a backend environment (batch
> processes).
>
>
>
> As this discussion is more or less already concluded, I hope that the spec
> can at least allow alternatives.
>
>
>
> BR,
>
> Kai
>
>
>
>
>
> *From: *George Fletcher 
> *Date: *Friday, 12. April 2024 at 19:53
> *To: *Atul Tulshibagwale 
> *Cc: *Brian Campbell , Kai Lehmann <
> kai.lehm...@1und1.de>, Dmitry Telegin , oauth <
> oauth@ietf.org>
> *Subject: *Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens
> issuance in the absence of incoming token
>
>
>
> Atul has submitted this PR to address this issue.
>
> https://github.com/oauth-wg/oauth-transaction-tokens/pull/90
> <https://urldefense.com/v3/__https://github.com/oauth-wg/oauth-transaction-tokens/pull/90__;!!FrPt2g6CO4Wadw!MJMc1NL3i2PsNlotzn7SBEzXnweUxiyc1sBVhxviBFDM_zf5l4muEFfQglVXdrP1XyOx-6BD_ilSfJBKaSgbcUATv14buN0ZfpAxA9o$>
>
>
>
> On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:
>
> Thanks all, for your input. We discussed alternatives on a call last week
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
>
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
> One potential benefit of keeping the use of Token Exchange is that some AS
> products/implementations have built a fair amount of configurability and
> extensibility into their Token Exchange support, which might allow for
> existing systems to be set up to do Transaction Tokens. Whereas a new
> endpoint or new grant type are more likely to require code changes to the
> core AS. Obviously this isn't universally true but something to consider
> nonetheless.
>
>
>
> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann  401und1...@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> that is my thought as well. It does not necessarily be a Token Exchange
> profile, but the Token endpoint makes sense as Tokens are issued. Defining
> a specific Token grant with the necessary input parameters would fit nicely.
>
>
>
> Best regards,
>
> Kai
>
>
>
> *From: *OAuth  on behalf of Dmitry Telegin
> 
> *Date: *Friday, 5. April 2024 at 00:41
> *To: *Atul Tulshibagwale 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
> incoming token
>
>
>
> Hello Atul,
>
>
>
> As an alternative to Token Exchange and separate (new) endpoint, have you
> ever considered OAuth 2.0 Extension Grants
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6749*section-4.5__;Iw!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthaF41vnj$>?
> This could give us more flexibility as will let us define our own set of
> input parameters and validation rules (opposite to Token Exchange that
> restricts us to subject_token and friends).
>
>
>
> Regards,
>
> Dmitry
>
>
>
> On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale  wrote:
>
> Thanks very much for your feedback, Joe!
>
>
>
> On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey  wrote:
>
> Hi Atul,
>
>
>
> I'm just starting to review the transaction tokens draft and have only a
> minimal understanding of the token exchange document at this point so I'm
> lacking a little background, but I have a few comments and questions below.
>
>
>
> On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale  wrote:
>
> Hi all,
>
> We had a meeting today (notes here
> <https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/HJNXYKkk0__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSyWxSbV$>)
> in which we discussed the question of what we should do if there is no
> incoming (external) token in t

Re: [OAUTH-WG] [External Sender] Comments on draft-ietf-oauth-transaction-tokens-01

[George Fletcher]

Hi Joe,

Thanks so much for the review. Comments inline (I'm only addressing some in
this email:)


On Wed, Apr 10, 2024 at 11:44 PM Joseph Salowey  wrote:

> I have reviewed the Transaction Token document.  In general I think it is
> a needed document and I am glad there is work in this area. I have some
> questions and comments below:
>
> 1. Section 4 defines Trust Domain and seems to point to RFC 7519.  I
> couldn't find any reference to trust domain in 7519.
>
> 2. Why would you not include a kid claim? it seems that key rotation
> should be supported. Is there harm in requiring a kid?
>
gff: There is no harm in supporting kid and I don't believe it's explicitly
excluded. It's probably useful to add some text around key rotation and use
of kid.

>
> 3. From the text, I don't really understand what the purp: claim is for.
>
gff: The goal of the claim is to allow the transaction token to "downscope"
the inbound token especially when it's from an external client. For
example, if the client is a mobile app with OAuth scopes for
readGroupMessaging and writeGroupMessaging (encapsulated in the
access_token). Then if the purpose of the transaction is to "add a user to
a group chat", then that can be explicitly codified in the Transaction
Token reducing the authorization scope of the token and tailoring the
transaction token to the purpose of the requested transaction. I need to
add more context as you are not the first to ask about it :)

>
> 4. One of the things I expected to see in some txn-tokens is a
> username/email, but I did not see that in any examples, while there are
> privacy considerations here, is there a reason why it is not included?
> Would this be in the rctx: or the azd: claim? It not clear when I would use
> azd or rctx for a particular data value.
>
gff: the subject claim can contain any value as makes sense for the Trust
domain. There is also no explicit restrictions on additional claims that
can be added. Note that Yaron has provided feedback on moving back to the
Security Event Token definition of sub_id which allows for more clear
identification of the subject value and its type.

>
> 5. As discussed on the list I think there may be cases where there will
> not be an Oauth token to exchange.  THe decision is that this is out of
> scope for this document, but the case should probably be mentioned.
>
gff: there is a pull request (#90 in github) covering this topic. The
proposed text requires a self-signed access token (potentially using RFC
9068) for the subject_token.

>
> 6. Is it intended that a single transaction token service endpoint can
> serve more than one trust domain? (it seems like the protocol supports, but
> I am not sure if it is a design goal).
>
gff: I would say the original intent is that there would be a single
transaction token service per trust domain. Happy to discuss that and the
pros and cons.

>
> 7. For a replacement token  7.4 it says the replacement may not change the
> rctx, but does not say anything about the azd.   In section 5.2 it says
> that azd: remains immutable during the call chain.  It seems that these two
> things do not line up and the replacement token needs something to change.
>  Perhaps azd is not immutable?  What are the asserted values that may
> change referred to in 7.4.1.
>
gff: Great catch!! Yes, that needs to be rectified.

>
> 8. Section 7.5 is referring to OAUTH client authentication? Should it
> refer to RFC 8705 for mTLS/SPIFFE case?
>
gff: so from a non-normative perspective, we can give that as an example.
Feel free to propose some text. The spec is intentionally silent on what
mechanism is used for client authentication.

>
> 9. Section 9.1 it probably should be mentioned earlier in the document
> that a transaction token cannot be issued based on a refresh token.
>
gff: I think I agree and that's something that hasn't been discussed
previously.

>
> Once again, thanks for your work on this document, I think it will be very
> useful.
>
> Joe
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!NrO-8pJTwTlsHifvL_LVyK8Mazovv7wSoS6xcnmxydwMzzrRSmc5WmBTQVtt8dekiooBnG0a26CP3XJcM0XI$
>

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete 

Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[George Fletcher]

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale  wrote:

> Thanks all, for your input. We discussed alternatives on a call last week
> ,
> and arrived at using self-signed tokens with token exchange as a way
> forward.
>
> On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell 
> wrote:
>
>> One potential benefit of keeping the use of Token Exchange is that some
>> AS products/implementations have built a fair amount of configurability and
>> extensibility into their Token Exchange support, which might allow for
>> existing systems to be set up to do Transaction Tokens. Whereas a new
>> endpoint or new grant type are more likely to require code changes to the
>> core AS. Obviously this isn't universally true but something to consider
>> nonetheless.
>>
>> On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann > 401und1...@dmarc.ietf.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> that is my thought as well. It does not necessarily be a Token Exchange
>>> profile, but the Token endpoint makes sense as Tokens are issued. Defining
>>> a specific Token grant with the necessary input parameters would fit nicely.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Kai
>>>
>>>
>>>
>>> *From: *OAuth  on behalf of Dmitry Telegin
>>> 
>>> *Date: *Friday, 5. April 2024 at 00:41
>>> *To: *Atul Tulshibagwale 
>>> *Cc: *oauth 
>>> *Subject: *Re: [OAUTH-WG] Transaction Tokens issuance in the absence of
>>> incoming token
>>>
>>>
>>>
>>> Hello Atul,
>>>
>>>
>>>
>>> As an alternative to Token Exchange and separate (new) endpoint, have
>>> you ever considered OAuth 2.0 Extension Grants
>>> ?
>>> This could give us more flexibility as will let us define our own set of
>>> input parameters and validation rules (opposite to Token Exchange that
>>> restricts us to subject_token and friends).
>>>
>>>
>>>
>>> Regards,
>>>
>>> Dmitry
>>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale  wrote:
>>>
>>> Thanks very much for your feedback, Joe!
>>>
>>>
>>>
>>> On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey  wrote:
>>>
>>> Hi Atul,
>>>
>>>
>>>
>>> I'm just starting to review the transaction tokens draft and have only a
>>> minimal understanding of the token exchange document at this point so I'm
>>> lacking a little background, but I have a few comments and questions below.
>>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> We had a meeting today (notes here
>>> )
>>> in which we discussed the question of what we should do if there is no
>>> incoming (external) token in the request to issue a Transaction Token
>>> 
>>> (TraT). We identified a few circumstances under which this can happen:
>>>
>>>- The requesting service is triggered by a non-OAuth based flow such
>>>as email or an internal trigger
>>>- The client of the requesting service uses means other than an
>>>access token to authorize the call (e.g. MTLS)
>>>
>>> [Joe] I think there will be a fair number of systems that support means
>>> of authorizing non-oauth flows.
>>>
>>>
>>>
>>>
>>>
>>> We identified a few possibilities listed below. Please note that the
>>> Transaction Tokens draft assumes that the TraT Service trusts the
>>> requesting service, so all the possibilities below assume this.
>>>
>>>
>>>
>>>
>>>
>>> [Joe] yes, you are trusting another part of the system to perform some
>>> authorization and inform the token service of the result.
>>>
>>>
>>>
>>> Here are some possibilities we discussed:
>>>
>>>1. *Request Details*: Put the subject information in the
>>>request_details parameter of the TraT request, and the subject_token 
>>> value
>>>is set to "N_A"
>>>2. *Self-Signed Token*: The requester generates a self-signed JWT
>>>that has the subject information and puts that in the subject_token value
>>>
>>> [Joe] I like having signed tokens, but if this is really information
>>> just exchanged between two endpoints it may be more work than necessary.
>>>
>>>
>>>1. *Separate Separate Endpoint*: The TraT service exposes a separate
>>>endpoint to issue TraTs when there is no incoming token, and that 
>>> endpoint
>>>can be defined such that the 

[OAUTH-WG] Draft 01 of Transaction Tokens posted

[George Fletcher]

Just a quick note to say that draft 01 of the Transaction Token spec has
been posted to the data tracker.

https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] [OAuth Transaction Tokens] PR #57 Update

[George Fletcher]

Hi,

I've updated PR #57 [1] to address the following issues:

Issue #56 [2] - RFC 9493 and sub_id formats
Issue #58 [3] - Authorization details presentation and processing
Issue #60 [4] - Use of actor_token and actor_token_type
Issue #61 [5] - How is the purp claim of the Txn-Token defined?

[1] https://github.com/oauth-wg/oauth-transaction-tokens/pull/57
[2] https://github.com/oauth-wg/oauth-transaction-tokens/issues/56
[3] https://github.com/oauth-wg/oauth-transaction-tokens/issues/58
[4] https://github.com/oauth-wg/oauth-transaction-tokens/issues/60
[5] https://github.com/oauth-wg/oauth-transaction-tokens/issues/61

Please review. I believe this closes the required updates for this PR.

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] Update and issues with the current transaction token draft

[George Fletcher]

Hi,

Based on feedback from a number of you, I've submitted a PR to the OAuth
Transaction Token draft to clarify how transaction tokens are requested and
obtained. You can find the PR here [1].

I've also created a number of new issues based on this work:
1. RFC 9493 and sub_id formats [2]
2. Authorization details presentation and processing [3]
3. Use of base64url encoding for request_context and authz_details [4]
4. Use of actor_token and actor_token_type [5]
5. How is the 'purp' claim of the Txn-Token defined? [6]

As always, reviews, feedback, corrections, etc are greatly appreciated!

[1] https://github.com/oauth-wg/oauth-transaction-tokens/pull/57
[2] https://github.com/oauth-wg/oauth-transaction-tokens/issues/56
[3] https://github.com/oauth-wg/oauth-transaction-tokens/issues/58
[4] https://github.com/oauth-wg/oauth-transaction-tokens/issues/59
[5] https://github.com/oauth-wg/oauth-transaction-tokens/issues/60
[6] https://github.com/oauth-wg/oauth-transaction-tokens/issues/61

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Transaction Tokens draft questions

[George Fletcher]

Hi Ken,

My apologies on the slow feedback. Comments inline...

On Fri, Dec 1, 2023 at 12:16 PM Ken McCracken  wrote:

> Hi,
>
> Thanks for the introduction in previous WG calls.  I am interested in
> providing Workload call chains in OAuth tokens, and based on
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-00
> 
> I have a few questions/feedback about specifics of the draft.
>
> 1. Section 5.2.1.  Why not use the “act” claim of RFC 8693, rather than
> introduce the new “sub_id” claim?
>
This is an interesting perspective. Are you suggesting that the transaction
token would not have a 'sub' claim at all and instead have the 'act' claim?
The general thinking for transaction tokens is that the subject of the
transaction token should be the identity of the entity the transaction is
about. I'm not sure the `act` claim captures that concept. Your thoughts?


> 2. Section 5.2.1.  Should the workload call chain, identifying each
> workload that has requested a new txn_token, be preserved in the txn_token
> claims-set, similar to the “act” claim of RFC 8693?  It may be that
> workloads deeper in the chain have no way to reason about prior actors, but
> maybe the spec should allow for the request call chain to optionally be
> preserved, in case upstream workloads can reason about downstream workloads.
>
For call chain "tracing" we are currently leaving that "out of scope" for
the specification as there may be many ways to provide that "pathing"
without having to re-request a new transaction token or wrap the original
one with another signature.


> 3. Section 7.2: In the text, it says “The token_type value MUST be set to
> txn_token", but I think it should say “The issued_token_type value MUST be
> set to urn:ietf:params:oauth:token-type:txn_token”
>
Yes, good catch. I'll update the spec. I was working on that section this
week :)


> 4. Section 7.2: I understand why you wouldn't want a refresh_token in the
> response.  Why can’t the response include expires_in or scope?
>
The issued transaction token has an `exp` and well as `purpose` claim that
cover both expires_in and scope. It felt redundant to put the same values
in both places. Do you see value in duplicating the values?

Thanks,
George


>
> Regards,
> -Ken McCracken
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IpEF7S3cfiMLLcMgo_pil_Z-ByInTtOwKlarEKZSo5FUFKBkEchL6mWXvTBGRAJMILrWtY2df57q5O05Z3wF6bjb9NKJLaQGHi8umQ8$
>

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] DPoP and Dynamic Client Registration

[George Fletcher]

Hi,

Are there any best practices for clients that want to use Dynamic Client
Registration and plan to register a public key (rather than receiving back
a shared client_secret), to use DPoP to prove possession of the
matching private key and also integrity protect the JSON object passed to
the registration endpoint?

I'm aware of the client attestation work but that isn't quite the same
thing.

Thoughts?

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Call for adoption - Identity Chaining

[George Fletcher]

I'm supportive of adoption

On Tue, Nov 14, 2023 at 7:59 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an *official* call for adoption for the *Identity Chaining *draft:
>
> https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/
> 
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by *Nov 28th.*
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!OyC9xgtqotJNHW3koj1oIIQd6r1xpEp306TlRaAR5PkNtTgd_RSn1BNImQBv_LGsRvUx0Qrpv0r1QWeXG-9cGD4L6_dsONA$
>

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Call for adoption - Transaction Tokens

[George Fletcher]

I'm supportive of adoption :)

On Tue, Nov 14, 2023 at 7:58 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an *official *call for adoption for the *Transaction Tokens *
> draft:
>
> https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/
> 
>
> Please, reply on the mailing list and let us know if you are in favor or
> against adopting this draft as WG document, by *Nov 28th*.
>
> Regards,
>  Rifaat & Hannes
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!Nqr30iiI7ZlobJ7_w7VgmNrHUE-0eih96FtpdSgKwLDYFcOuo0_uHrDa8DEBi2mG0DqTFjZbP-FmrKIkAR5ww54RQJ2lbcI$
>

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Re: Questions on OAuth Protected Resource Metadata

[George Fletcher]

Hi Justin,

Whether the scopes are known or unknown to the developer, I don't think it
changes the "attack vector" which is to get the client to request more
privilege than it should in a given circumstance. Maybe the attacker has a
way to capture the token once it issues (this of course can be mitigated by
using sender constrained tokens but how many are deploying that solution
internally?).

I think a security consideration makes sense given the client is likely
just going to use whatever is provided in the meta-data. Either the AS
needs a way to ensure clients only request the authorization needed for the
current task, or clients need a way to filter the scopes specified. The
latter is more likely but we don't have a good way to convey the intent of
the access token outside of the Resource Indicators specification (which
again I'm not sure is widely implemented).

Thanks,
George

On Tue, Sep 26, 2023 at 10:54 AM Justin Richer  wrote:

> I think we’re used to thinking of scopes in terms of things that a
> developer can read and understand, but that’s not always going to be true.
> For automated systems like this, the developer isn’t always expected to
> understand the scope — they probably don’t even see it in many cases. The
> client software knows the API, but at the OAuth layer, the client just
> needs to know what values to put into the OAuth flow to be able to call the
> RS and have it work. That value could very well be an opaque string, which
> is supported by the 6750 response header already as well.
>
>  — Justin
>
> On Sep 22, 2023, at 1:58 PM, Atul Tulshibagwale  wrote:
>
> Hi,
>
> #1 is clear now. Thanks Warren
> On #2, thanks Neil and Warren for your clarifications. Does it make sense
> to include language that warns against requesting unknown scopes in the
> OPRM draft?
>
> Atul
>
> On Thu, Sep 21, 2023 at 11:17 AM Neil Madden 
> wrote:
>
>> On 21 Sep 2023, at 17:19, Atul Tulshibagwale  wrote:
>>
>>
>> Hi all,
>> I'm still looking for answers to these two questions
>> 
>> regarding the OPRM draft that was recently adopted by the WG:
>>
>>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.
>>
>> Regarding point 2, if this is a threat then it's already enabled by RFC
>> 6750, which defines the `WWW-Authenticate: Bearer scope="..."` challenge
>> header that can be used to indicate which scopes a client needs to access a
>> resource. Even just misleading documentation for how to access the RS could
>> enable this threat. That's not to say that this isn't worth considering (it
>> is), but I don't think this draft makes the situation worse than now.
>>
>> -- Neil
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MEkYNnqe_LL_FW1ouclB0RBHsbCXu5Sr6qR4EVjLtaJjO3I0Zs2HnTOPGRxPOFdyzUU0SgtBOKJmDjfgrbbg2Cqq$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information 

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

[George Fletcher]

Hi Atul,

I think this is the beginning of a really interesting discussion. I'm
wondering if we should start a different thread. The recent OAuth Step-up
spec could help in this regard and static RS documentation could be used to
describe which scopes are needed for which endpoints. However, as we move
authorization to be more fine-grained I'm wondering if "scopes" is really
the right mechanism :)

Thanks,
George

On Thu, Aug 31, 2023 at 7:51 PM Atul Tulshibagwale  wrote:

> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0vbvkqcw$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

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

[George Fletcher]

I support adoption

On Wed, Aug 23, 2023 at 3: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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N3eHl0YpRs7mk3Niha-f2vGraeF6zjLtJwlQpC17BwfhCrFnQowfQS4DzPRhEko5oKeWd3BaSkBBqb-nK8eEzNAUCMg3yik$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Re: OAuth Trust model

[George Fletcher]

On Thu, Aug 10, 2023 at 4:30 PM Hans Zandbelt 
wrote:

> On Thu, Aug 10, 2023 at 9:40 PM George Fletcher  40capitalone@dmarc.ietf.org> wrote:
>
>> Hi Matthias,
>>
>> First, OAuth is about authorization and NOT authentication. If you are
>> concerned with Authentication then this thread should move to the OpenID
>> Connect working group mailing list :)
>>
>
>  Allow me to set the public record straight on this before it starts to
> lead its own life: OpenID Connect does not deal with Authentication - at
> all - and in fact has the very same relationship with Authentication as
> OAuth 2.0 does: at some point user Authentication may happen, but it is
> completely undefined and orthogonal to the OAuth/OIDC protocol. OpenID
> Connect should rather be thought of as delegation of access to a user's
> identity (thanks to Justin who - I believe - posed the latter definition).
> I guess you actually meant to say "Identity" in the 2nd sentence above
> instead of "Authentication",  and I agree that this discussion seems to be
> about OIDC indeed.
>

Thanks for the clarification Hans. I agree that the actual process of
authenticating is out of scope for OpenID Connect as well. The distinction
I was trying to make (poorly it turns out) is that OpenID Connect is about
transferring information about the identity while OAuth does not need to
include any identity attributes at all.


>
> Second, if I'm understanding the problem correctly, the issue is NOT with
>> OAuth (the protocol) or the Authorization Server. The issue is with the
>> "relying party" where the user originally signed up with an email address
>> (e.g. f...@example.com). In the case described, the "relying party" took
>> the email address provided by the authorization server and looked in its
>> own identity store to see if there was a match. It found a match and
>> automatically linked those "identities" (in an attempt to help ensure the
>> user does not unintentionally create multiple identities when they didn't
>> intend to). The RP could present a page to the user to ask if they want to
>> link the identities and then if the user does want to link, verify the user
>> is the correct owner of the original account before linking.
>>
>
> I agree that account linking really only happens when the user has an
> authenticated session at the RP, possibly asking to re-authenticate once
> more. In that case the user explicitly trusts the Provider, and whatever
> the Provider can do afterwards is a result of that - as goes for any
> trusted IDP - which addresses Matthias's 1st concern. This also means that
> the 2nd concern - "unsolicited linking" - is not possible IRL and certainly
> not in the Stackoverflow/Github example. It is true though that "explicit
> (re)authenticated account linking" is not included in any RFC/BCP, then
> again account linking in itself isn't since it is not (very)
> protocol-related.
>

I'm not sure I completely agree with the statement that the user needs to
be authenticated at the RP before the linking flow can start. I agree that
authentication at the RP must eventually complete if the link is to go
through but it could start without the user first being authenticated at
the RP. However, this is not really a relevant point :)


>
> So for me, resolving this issue is out of scope for the OAuth protocol.
>>
>
> Agree, Auth for sure ;-)
>
> Hans.
>
>
>>
>> Thanks,
>> George
>>
>> On Thu, Aug 10, 2023 at 4:25 AM Warren Parad > 40rhosys...@dmarc.ietf.org> wrote:
>>
>>> You've lost me at this:
>>>
>>> Some site, which I'm registered in is trusting some oauth provider I'm
>>>> not even knowing about. I'm not registered at this provider. If this
>>>> provider is (independent how or from whom) is used in a malicious way, they
>>>> can access my account, without my knowledge by sending a valid token
>>>> including my email.
>>>
>>>
>>> Nothing stops a site you are using, registered with your email address,
>>> from just selling your data to a third party, or blanket publishing it
>>> publicly. There is nothing we can do to stop this unless the data we care
>>> about is encrypted on the client side. OAuth doesn't really have anything
>>> to do with it.
>>>
>>> Because it has nothing to do with OAuth, the suggested solution of
>>> course must have a hole with it. And indeed it does. What if the site
>>> offers the token strategy, but then decides to outsource the whole
>>> authentication process to a different third party? We are

Re: [OAUTH-WG] [External Sender] Re: OAuth Trust model

[George Fletcher]

Hi Matthias,

First, OAuth is about authorization and NOT authentication. If you are
concerned with Authentication then this thread should move to the OpenID
Connect working group mailing list :)

Second, if I'm understanding the problem correctly, the issue is NOT with
OAuth (the protocol) or the Authorization Server. The issue is with the
"relying party" where the user originally signed up with an email address
(e.g. f...@example.com). In the case described, the "relying party" took the
email address provided by the authorization server and looked in its own
identity store to see if there was a match. It found a match and
automatically linked those "identities" (in an attempt to help ensure the
user does not unintentionally create multiple identities when they didn't
intend to). The RP could present a page to the user to ask if they want to
link the identities and then if the user does want to link, verify the user
is the correct owner of the original account before linking.

So for me, resolving this issue is out of scope for the OAuth protocol.

Thanks,
George

On Thu, Aug 10, 2023 at 4:25 AM Warren Parad  wrote:

> You've lost me at this:
>
> Some site, which I'm registered in is trusting some oauth provider I'm not
>> even knowing about. I'm not registered at this provider. If this provider
>> is (independent how or from whom) is used in a malicious way, they can
>> access my account, without my knowledge by sending a valid token including
>> my email.
>
>
> Nothing stops a site you are using, registered with your email address,
> from just selling your data to a third party, or blanket publishing it
> publicly. There is nothing we can do to stop this unless the data we care
> about is encrypted on the client side. OAuth doesn't really have anything
> to do with it.
>
> Because it has nothing to do with OAuth, the suggested solution of course
> must have a hole with it. And indeed it does. What if the site offers the
> token strategy, but then decides to outsource the whole authentication
> process to a different third party? We are back at the same problem again.
> However it sounds like what you are saying is that there should be a
> standardized mechanism for handling the site <=> user token verification.
> If we use OAuth terminology that would be: We should allow *step-up
> authentication* to occur solely between the *resource server (RS)* and
> the *user agent* without involving the *authorization server (AS)*. But
> then who generates the new JWTs? If the AS generates the new one then, we
> didn't stop anything. And if the RS generates the new one then actually the
> AS isn't needed to do anything.
>
> And that latter case is actually the reality if we consider these tokens
> to be a 2FA mechanism that is managed by the site/resource server. So I
> read this as, we should standardize *WebAuthn *communication between a *user
> agent* and the *resource server. *That already exists though, doesn't it?
>
> On Thu, Aug 10, 2023 at 12:59 AM Matthias Fulz  wrote:
>
>> I'm trying to explain my concern more deeply, please try to follow my
>> thinking.
>>
>> First: Everything you've written is correct and I fully agree.
>>
>> But: The difference is: I'm deciding, that I'm using email from xy, I'm
>> deciding, that I'm using this email to register at some site or anything.
>>
>> Anything of these services could be hacked of course, and then they can
>> use my mail to reset password, use the accounts, etc.
>>
>> Now think from the other side:
>>
>> Some site, which I'm registered in is trusting some oauth provider I'm
>> not even knowing about. I'm not registered at this provider. If this
>> provider is (independent how or from whom) is used in a malicious way, they
>> can access my account, without my knowledge by sending a valid token
>> including my email.
>>
>>
>> I'm not sure how to explain the main concern about this in more detail
>> and of course I can avoid services providing these type of logins without
>> my permission, but as said what about the future?
>> On 8/10/23 00:40, Warren Parad wrote:
>>
>> Let me try that differently, is OAuth more vulnerable than email usage?
>> If you hacked any email provider that's arguably a bigger goldmine than
>> just ones protected by oauth. As long as sites are protected by email,
>> oauth gives a more secure strategy. Most providers that accept email as
>> authentication allow you to reset your password via email.
>>
>> Going further, "email is insecure" because providers that send email can
>> impersonate you. How about telecom companies, they can pretend to send SMS
>> from you. Or the government, they could issue a new password in your name
>> and pretend to be you. The horror.
>>
>> In all seriousness, it's about your threat modal more than anything.
>> Concerned about your email, then that's your weak point, concern about
>> oauth, we'll first be concerned about your email, and then you can be
>> concerned about oauth.
>>
>> If we assume that 

Re: [OAUTH-WG] [External Sender] Re: IETF OAuth WG Virtual Office Hours

[George Fletcher]

I will not make today’s meeting

On Wed, Aug 9, 2023 at 11:33 AM Sanesh Narayanan <
saneshnarayananin...@gmail.com> wrote:

> Go ahead and start without me.
>
> sanesh chazhiyottil
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!PIOP6Ps-tguAybf6Wyryi22YlsRMAMYBlGyZHjlVyY9kAkCCh6KvGUwF7ZgREPN5jCIO2WlQAAvGXszG_y8d-CmJt9wzazAsXFA$
>
-- 
[image: Capital One]

George Fletcher (he/him)

Executive Distinguished Engineer • Identity Architect
[image: address]8020 Towers Crescent Drive, Vienna, VA 22128
[image: mobile]616-498-8240

assistant: [image: email] genevieve.mor...@capitalone.com

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Re: Feed back on draft-sh-rats-oidc at-00

[George Fletcher]

Hi Ned,

I'm not sure how best to thread any responses...

Regarding terminology and definitions: I agree that this should be done and
be added to whatever document(s) are adopted by the working group. In
general, I suspect that within the OAuth working group "attestation" is a
general term describing a set of attributes that is signed by an entity the
receiver trusts that gives greater confidence that the client is an
application that the receiver is willing to work with.

>From a layering perspective, while not providing full confidence, I believe
most OAuth/OpenID Connect implementations are looking for statements
about the application and the device (e.g. jailbroken or not). The
motivation behind the "draft-looker-oauth-attestation-based-client-auth-00"
draft is a way for wallets (clients running on a mobile phone) to prove
their "authenticity" to an issuer so that the issuer will issue a
credential into the wallet. In this use case the issuer is acting kind of
like an AS and the wallet approximates an RP. When the wallet wants to
present claims to a verifier then the wallet takes on the role of the AS
and the verifier takes on the role of the RP. There is debate within the
OAuth working group as to whether "attestations" are needed between the
wallet and the verifier.

[nms] RFC9334 tries to point out that an Attester shouldn’t attempt to
self-attest as that implies the Attester can lie about its state. Rather,
an Attesting Environment (which is trusted) should collect Evidence about
the “client”.

>From a practical implementation perspective, the expectation is that the
attributes about the client and device come from the OS platform and are
not self-asserted. In Tobias' draft, the client backend is just there to
have a persistent set of signing credentials over the attributes obtained
from the OS platform.

However, this is an important point in any of this work as it's critical
for the receiver of the signed attributes to be able to trust them and that
they are misrepresented.


[nms] I agree a nonce would be useful. However, there are use cases where
the Attester is composed of multiple environments and some of those
environments are measured at different times (e.g., at boot time).
Therefore, it isn’t practical (usually) for a single nonce from the AS to
be the sole form of Evidence freshness.

This gets to the completeness of the solution and how much of that is
required for the purpose of increasing trust in the client. I suspect that
within the OAuth working group the focus is on OS platform "attested"
attributes. This includes who wrote the application. Other statements about
the boot structure of the device and all its layers may be deemed less
critical. Another discussion we should have on the list.


Hopefully others will join in as it looks like the
draft-looker-oauth-attestation-based-client-auth-00 will be accepted by the
working group.

Thanks,
George

On Fri, Jul 28, 2023 at 11:30 PM Smith, Ned  wrote:

> George,
>
> Thanks for the detailed responses. I have a few questions / comments
> inline.
>
> Thanks,
>
> Ned
>
>
>
> *From: *George Fletcher 
> *Date: *Friday, July 28, 2023 at 11:47 AM
> *To: *"Smith, Ned" , Thomas Hardjono <
> hardj...@mit.edu>, "oauth@ietf.org" 
> *Subject: *Feed back on draft-sh-rats-oidc at-00
>
>
>
> Hi Ned/Thomas,
>
>
>
> Thanks so much for the conversation at IETF on the potential value of
> combining the attestation work with OpenID Connect and OAuth. Given the
> spec references a lot of OpenID Connect artifacts, I’ve used OpenID Connect
> points in this response. However, from an IETF perspective, this would be
> connected to OAuth and the Authorization Server. It might be useful to map
> the work to OAuth directly and then let OpenID Connect (which is built on
> top of OAuth) to “inherit” the capability.
>
>
>
> As promised, here is some feedback on the presented draft…
>
>
>
> Section 2.1
>
> * The userinfo endpoint is an API specified by the OpenID Connect
> protocol. It’s usually part of the OpenID Provider. Regardless it’s not a
> useragent/browser.
>
>
>
> Section 3.1
>
> * userinfo (see previous comment)
>
> * End user (EU/Alice) is not an application. In OAuth the end user is
> called the Resource Owner. The application is called the ‘client’. So the
> Resource Owner uses the client to access the RO’s resources.
>
> * Relying Party - generally in OAuth/OpenID Connect the relying party is
> not looking for attestations. It’s looking for an authorization token to be
> presented by a client. In the case of attestations… it would be the OpenID
> Provider that would be interested in the attestations (in this context it
> may be possible to consider the OpenID
>
>
> 

Re: [OAUTH-WG] [External Sender] Call for adoption - Attestation-Based Client Authentication

[George Fletcher]

I support adoption. I hope we consider a lot of the points raised in the
discussion that the “attestation” is useful in many contexts and not just
“client authentication” at the /token endpoint.

Thanks,
George

On Sat, Jul 29, 2023 at 3:27 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> This is an official call for adoption for the *Attestation-Based Client
> Authentication *draft discussed in SF.
>
> https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/
> 
>
> Please, reply on the mailing list and let us know if you are in favor of
> adopting this draft as WG document, by *August 11th*.
>
> Regards,
>  Rifaat & Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!K0HoWFFk981IbOPwLikwWdc4qZqKnFE37WHdEvR94lc7SzO9fGspxWCuoSq65_IdKVNxRA04lWHZ6ghz9sU1-DWuVMUWkdQ$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Re: Call for adoption - SD-JWT-based Verifiable Credentials

[George Fletcher]

+1 for me

On Sat, Jul 29, 2023 at 3:36 PM Michael Prorock  wrote:

> I support adoption - but would request that if a group dedicated to
> verifiable credentials is created prior to this draft being finalized, that
> the group consider moving this draft to that group.
>
> Mike Prorock
> CTO - mesur.io
> <https://urldefense.com/v3/__http://mesur.io__;!!FrPt2g6CO4Wadw!KTY6CXfa-1acXzS4XB2ig8SrMoLTrb4vb_r_uxZt2cpjg3_VjEwxkfOdC8LReNBhwz3s2GIbQWjAR7T2BK3kt80-7w$>
>
> On Sat, Jul 29, 2023, 12:26 Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> This is an official call for adoption for the *SD-JWT-based Verifiable
>> Credentials *draft discussed in SF.
>> https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/__;!!FrPt2g6CO4Wadw!KTY6CXfa-1acXzS4XB2ig8SrMoLTrb4vb_r_uxZt2cpjg3_VjEwxkfOdC8LReNBhwz3s2GIbQWjAR7T2BK2HEZMW6Q$>
>>
>> Please, reply on the mailing list and let us know if you are in favor of
>> adopting this draft as WG document, by *August 11th*.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!KTY6CXfa-1acXzS4XB2ig8SrMoLTrb4vb_r_uxZt2cpjg3_VjEwxkfOdC8LReNBhwz3s2GIbQWjAR7T2BK25l3OfYw$>
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!KTY6CXfa-1acXzS4XB2ig8SrMoLTrb4vb_r_uxZt2cpjg3_VjEwxkfOdC8LReNBhwz3s2GIbQWjAR7T2BK25l3OfYw$
>
-- 
[image: Capital One]

George Fletcher (he/him)

Executive Distinguished Engineer • Identity Architect
[image: address]8020 Towers Crescent Drive, Vienna, VA 22128
[image: mobile]616-498-8240

assistant: [image: email] genevieve.mor...@capitalone.com

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] Feed back on draft-sh-rats-oidc at-00

[George Fletcher]

Hi Ned/Thomas,

Thanks so much for the conversation at IETF on the potential value of
combining the attestation work with OpenID Connect and OAuth. Given the
spec references a lot of OpenID Connect artifacts, I’ve used OpenID Connect
points in this response. However, from an IETF perspective, this would be
connected to OAuth and the Authorization Server. It might be useful to map
the work to OAuth directly and then let OpenID Connect (which is built on
top of OAuth) to “inherit” the capability.

As promised, here is some feedback on the presented draft…

Section 2.1
* The userinfo endpoint is an API specified by the OpenID Connect protocol.
It’s usually part of the OpenID Provider. Regardless it’s not a
useragent/browser.

Section 3.1
* userinfo (see previous comment)
* End user (EU/Alice) is not an application. In OAuth the end user is
called the Resource Owner. The application is called the ‘client’. So the
Resource Owner uses the client to access the RO’s resources.
* Relying Party - generally in OAuth/OpenID Connect the relying party is
not looking for attestations. It’s looking for an authorization token to be
presented by a client. In the case of attestations… it would be the OpenID
Provider that would be interested in the attestations (in this context it
may be possible to consider the OpenID Provider playing the role of a RRP).

Section 3.2.1
* this isn’t really how the OpenID connect protocol works. In a general
mobile app flow, the mobile app (aka the client) will open a browser to the
OpenID Provider’s /authorization endpoint which starts the
authentication/consent/authorization flow. Once the user has authenticated,
the OpenID Provider provides a ‘code’ back to the native application which
then exchanges that ‘code’ for the ‘id-token and access-token’ at the
/token endpoint of the OpenID Provider

Beyond this part of the spec I got confused on how the protocol is supposed
to work and who the core agents are in the flow. A diagram would be really
helpful showing the core steps.

In my view, it’s more likely that the OpenID Provider will be the entity
desiring an attestation about the client making the request. This could be
just an attestation about the client software, or could also include an
attestation about general characteristics of the device (e.g. is it jail
broken or not).

There are two main use cases…
1. The client is a mobile app in which case it may be able to obtain an
attestation before starting the authorization flow
2. The client is a web service (or relying party) and the OpenID Provider
wants some attestation about the software and environment in which that
client is running.

I suspect we can address both cases with the same flow. We might need an
initial step for the client to obtain a nonce from the OpenID Provider
before presenting the attestation so that the attestation can contain the
nonce allowing the OpenID provider to know this is a fresh attestation and
bound into the authorization process requested by the client.

Thanks,
George
-- 
[image: Capital One]

George Fletcher (he/him)

Executive Distinguished Engineer • Identity Architect
[image: address]8020 Towers Crescent Drive, Vienna, VA 22128
[image: mobile]616-498-8240

assistant: [image: email] genevieve.mor...@capitalone.com

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] [External Sender] Re: Collective name for attacks on cross-device flows: Cross-Device Consent Phishing (CDCP)

[George Fletcher]

I'm a +1 for the name

On Thu, Jun 15, 2023 at 11:04 AM Aaron Parecki  wrote:

> I like it, it's definitely the best out of the list.
>
> Aaron
>
> On Thu, Jun 15, 2023 at 7:57 AM Pieter Kasselman  40microsoft@dmarc.ietf.org> wrote:
>
>> Hi folks, one of the discussion points at IETF 116 for the cross-device
>> security BCP was finding a collective name for the exploits of the cross
>> device flows we were seeing. We got several suggestions since then (see
>> list below).
>>
>>
>>
>> We are thinking of adopting the term “Cross-Device Consent Phishing
>> (CDCP)” given that it describes the scope of the attacks (cross-device),
>> the purpose of the attacks (obtaining user consent), and the technique
>> (phishing, and other social engineering techniques).
>>
>>
>>
>> Does this feel like a good descriptive name to adopt?
>>
>>
>>
>> The list of names that was suggested over the last few months:
>>
>>
>>
>>1. Cross-Device Consent Phishing
>>2. Illicit Consent Grant Attack
>>3. Attacker-in-the-Middle Attack
>>4. Authorization Context Manipulation Attack
>>5. Authorization Context Manipulation Exploit
>>6. "Cross-Device Authorization Exploit"
>>7. "Social Engineering Token Theft"
>>8. "Authorization Flow Manipulation Exploit"
>>9. Context Manipulation Authorization Exploit
>>10. Zishing
>>11. Azishing
>>12. FlowJack
>>13. AuthJack
>>14. TokenJack
>>15. Permitphishing,
>>16. Authishing
>>
>>
>>
>> Cheers
>>
>>
>>
>> Pieter
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MiVGjrrSZVrFfqf5H3kVV6POC4gNvh4iM5j_St4tWh0T_-9MQOlgEBWH6kUuh1RtUeBGH_FynAidy_YXHRrQoFVGgaI2Y3MQ738ijjY$
>

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

[OAUTH-WG] Native Apps UX and HTML alternatives

[George Fletcher]

I'm trying to catch Justin's attention with that subject header :-)

This is more just for historical purposes. The desktop AOL client was
basically a rendering engine of a binary protocol called FDO (two versions
88 and 91). This protocol supported both markup and scripting optimized for
transfer over modems.

Additionally, AOL developed another protocol called Nachos with similar
capabilities targeted at hand held devices.

I suspect these will not be the last :)  Maybe there is room to allow such
mechanisms while still standardizing how a native mobile app can inform the
AS that it wants to use a supported mechanism (can be out of scope; or a
separate spec) to interact with the user.

While the most common case will be authentication, I think we may need to
enable these "challenge/response" mechanisms to also handle registration,
recovery and other life cycle flows.

Thanks,
George

__



The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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

Re: [OAUTH-WG] OAUTH for Web Proxy authentication

[George Fletcher]

To my knowledge that spec doesn't exist. I'll let others chime in if 
they have seen a proposal in that regard.


In regards to which working group, given the core topic is OAuth 
authorization, I would present it here at a minimum.


Thanks,
George

On 1/22/23 7:06 AM, Markus PlusNet wrote:

Dear WG,
    I am new to oauth and wonder which WG would be responsible for 
reviewing a Spec for Proxy authentication 
https://httpwg.org/specs/rfc9110.html#auth.client.proxy using oauth or 
does that spec already exist ?

Thank you
Markus

___
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] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

[George Fletcher]

I just want to make a quick comment on the use of "proximity and 
location information". I used the device flow to authorize my son's 
device by having him text me the code so I could login on my device (in 
a different state) and provide his device access. If we close the door 
too much we will potentially impact good users :)


I agree that consent can be socially engineered... but think that it 
would be useful to improve that information so that the user 
authenticating to provide authorization could know where the device 
their authorizing is located. That could help users detecting that they 
are authorizing a device in a location that doesn't make sense to them.


Thanks,
George

On 3/18/22 8:21 AM, Pieter Kasselman wrote:


Hi Brock

Great point, and I would agree that better consent screens could help, 
but I don’t think it is sufficient.


One of the challenges with consent screens is that it makes 
assumptions about the users abilities when they are being asked to 
make decisions about things they do not fully appreciate or 
understand. In addition, they are in a rush, are often trying to be 
helpful and prone to grant consent (the framing in these social 
engineering attacks can be very persuasive). Even users who are aware 
of these exploits and understand the systems they interact with are 
prone to be misled. Better guidance on the consent screen is 
definitely something we should provide.


I do think there is a defence in depth strategy that can reduce risk 
by (1) avoiding asking the user for a decision by making back-end risk 
decisions (2) augmenting the information presented to the user when 
making the decisions and (3) mitigating against a decision made in error.


Proximity and location information can for instance be used to bind 
user codes to specific locations or inform the user on where the user 
code was first presented, device status and/or location may be used to 
make decisions on whether to allow device code flows to be used in the 
first place and use of token binding (e.g. DPoP) may help defend 
against attackers who are able to exfiltrate tokens from a device and 
make lateral attacks.


Anything we can do to encourage implementor to ask users to make fewer 
decision, help them make better decisions and then protecting them in 
case of a bad decision will help drive down risk.


Cheers

Pieter

*From:*Brock Allen 
*Sent:* Thursday 17 March 2022 21:25
*To:* Pieter Kasselman ; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and 
Illicit Consent Exploits


I watched one of those videos and it seems to be that a proper consent 
screen would have been the best and easiest line of defense. Is there 
something more to the attacks where a better consent page (or any 
consent page for that matter) would not have been sufficient?


-Brock

On 3/17/2022 5:10:35 PM, Pieter Kasselman
 wrote:

Hi All

One of the agenda items for IETF 113 is the device authorization
grant flow (aka device code flow), scheduled for Thursday 24 March
2022.  Before the meeting, I wanted to share a bit more
information for those interested in the topic and also give those
who are unable to attend in person an opportunity to participate
in the conversation.

The Device Authorization Grant Flow (RFC 8682)

solves
an important problem by enabling authorization flows on devices
that are unable to support a browsers or have limited input
capabilities. However, looking back over the past 18-24 months,
there have been a number of practical exploits published that use
social engineering techniques applied to the device authorization
grant flow.

The goal of the session at IETF 113 is to discuss the patterns of
the exploits that are known and start a conversation on what (if
anything) we should do, based on what we are learning.

These exploits follow a general man-in-the-middle (MITM) pattern,
where the attacker:

 1. Initiates the Device Authorization Grant flow on a device
under their control,
 2. Presents the user code in a context that the end-user is
likely to act on (using social engineering techniques), and
 3. Once the user grants access, retrieves the access and refresh
tokens and uses them to access the user’s resources.

Some of the exploits are described here for those interested in
more detail:

 1. The Art of the Device Code Phish - Boku (0xboku.com)

Re: [OAUTH-WG] proof of access token possession using client secret

[George Fletcher]

You could require client authentication via the allowed OAuth mechanisms 
on all resource requests. I think there is some danger in sending the 
client_secret across the wire on all requests even if the endpoints are 
all part of the same service. I'd recommend looking at DPoP [1].


Thanks,
George

[1] https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-06

On 3/2/22 11:22 AM, Jim Manico wrote:


> I would like to prevent clients from sharing their access tokens. I 
am wondering if requiring clients to include the "client secret" in 
the resource access request (in addition to the access token) is a 
valid strategy.


Sender-constrained access tokens are suggested in the current security 
best practice guide here. 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-2.2


So yes!

- Jim Manico

On 3/2/22 8:18 AM, Warren Parad wrote:
Is there a reason you wouldn't want to use the access token to access 
these resources? That seems like it would be the optimal strategy.




Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a service. Implement 
Authress .



On Wed, Mar 2, 2022 at 4:58 PM Nikos Fotiou  wrote:

Hi all,

I am working on a use case where the Authorization Server and the
Resource Server are the same entity. I would like to prevent
clients from sharing their access tokens. I am wondering if
requiring clients to include the "client secret" in the resource
access request (in addition to the access token) is a valid
strategy. This way clients would have to share their "client
secret" in addition to the access token. Would that work?

Best,
Nikos
--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

___
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

--
Jim Manico
Manicode Security
https://www.manicode.com

___
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] DPoP and client registration metadata

[George Fletcher]

On 2/17/22 4:32 PM, Brian Campbell wrote:
On Thu, Feb 17, 2022 at 12:28 PM George Fletcher 
 wrote:


Given that the FAPI 2 baseline is requiring either DPoP or MTLS as
the sender-constraining methods, I think we need to provide more
guidance about how DPoP is used in cases outside of SPAs. Can a
mobile app using dynamic client registration via pub/priv key pair
generated on the device using the same public key for the DPoP
required portions of the flows?


It could use the same key but there's nothing requiring it or checking 
any association. In 
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-04.html#section-1-3 
we say "DPoP can be used to sender-constrain access tokens regardless 
of the client authentication method employed, but DPoP itself is not 
used for client authentication." Which is meant to say that DPoP is 
orthogonal to client auth.


Ok, I guess I was wondering if there are any security implications of 
using the same key or benefits of using different keys that might be 
helpful for developers.




On 2/14/22 5:51 PM, Brian Campbell wrote:
This (more or less) has come up again in the from of a github issue: 
https://github.com/danielfett/draft-dpop/issues/105 and it has me 
sort of maybe reconsidering the idea of introducing some kind of 
client metadata that indicates that the client will always do DPoP. 
So I wanted to bring it up again here on the list to try and see what 
folks had opinions on it.


On Tue, Oct 26, 2021 at 4:08 PM Brian Campbell 
 wrote:


There are no plans to introduce client registration metadata for
DPoP - the requirement to use DPoP is more of a property of a
resource so I don't think registration metadata for a client fits
very well.


On Tue, Oct 26, 2021 at 8:53 AM Dmitry Telegin
 wrote:

For dynamically registered clients, there is currently no way
to indicate the intention to use DPoP. Hence, it's completely
up to the AS whether to enforce DPoP or not on such clients
(for example, using client registration policies).

Seems like there is no common approach here; for example, RFC
8705 (OAuth 2.0 Mutual-TLS Client Authentication and
Certificate-Bound Access Tokens) does define client
registration metadata (see section 9.5), whilst RFC 7636
(PKCE) does not. I guess this is due to PKCE being initially
conceived as a feature that would become mandatory in OAuth 2.1.

Are there any plans to introduce client registration metadata
for DPoP?

Regards,
Dmitry
Backbase

___
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



/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] DPoP and client registration metadata

[George Fletcher]

From an authorization server perspective, I think it makes sense to be 
able to flag certain clients as only supporting DPoP bound tokens and 
hence rejecting any request without the appropriate proof.


Given that the FAPI 2 baseline is requiring either DPoP or MTLS as the 
sender-constraining methods, I think we need to provide more guidance 
about how DPoP is used in cases outside of SPAs. Can a mobile app using 
dynamic client registration via pub/priv key pair generated on the 
device using the same public key for the DPoP required portions of the 
flows?


Thanks,
George

On 2/14/22 5:51 PM, Brian Campbell wrote:
This (more or less) has come up again in the from of a github issue: 
https://github.com/danielfett/draft-dpop/issues/105 and it has me sort 
of maybe reconsidering the idea of introducing some kind of client 
metadata that indicates that the client will always do DPoP. So I 
wanted to bring it up again here on the list to try and see what folks 
had opinions on it.


On Tue, Oct 26, 2021 at 4:08 PM Brian Campbell 
 wrote:


There are no plans to introduce client registration metadata for
DPoP - the requirement to use DPoP is more of a property of a
resource so I don't think registration metadata for a client fits
very well.


On Tue, Oct 26, 2021 at 8:53 AM Dmitry Telegin
 wrote:

For dynamically registered clients, there is currently no way
to indicate the intention to use DPoP. Hence, it's completely
up to the AS whether to enforce DPoP or not on such clients
(for example, using client registration policies).

Seems like there is no common approach here; for example, RFC
8705 (OAuth 2.0 Mutual-TLS Client Authentication and
Certificate-Bound Access Tokens) does define client
registration metadata (see section 9.5), whilst RFC 7636
(PKCE) does not. I guess this is due to PKCE being initially
conceived as a feature that would become mandatory in OAuth 2.1.

Are there any plans to introduce client registration metadata
for DPoP?

Regards,
Dmitry
Backbase

___
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] DPoP and OpenID Connect

[George Fletcher]

It's probably better to post this question in the OIDC working group 
email list or file an issue with OpenID Connect. I think it is an 
interesting and relevant question.


OpenID Connect does define the 'private_secret_jwt' mechanism which can 
be used for client authentication and could be bound with the access or 
refresh token.


Thanks,
George

On 2/16/22 6:03 PM, Dmitry Telegin wrote:
Could we somehow clarify the relationship between DPoP and OIDC? 
(sorry if this is the wrong ML)


For example, it's relatively obvious that the OIDC UserInfo should 
support DPoP, as it is an OAuth 2.0 protected resource. What's not 
obvious is that the WWW-Authenticate challenge (in case of 401) will 
most likely contain multiple challenges (Bearer and DPoP), and it 
could be a bit tricky from the browser compatibility PoV.


Another non-obvious thing is that ID tokens could be DPoP-bound as 
well. Some technologies even rely on it, Solid-OIDC being a notable 
example: https://solid.github.io/solid-oidc/#tokens-id


Dmitry
Backbase / Keycloak

___
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] DPoP proof and the public key

[George Fletcher]

Hi,

I'm going to expose my ignorance here... but what is the rationale for 
requiring the public key in every DPoP proof? Is there a security 
reason? or is it for ease of development? If large RSA keys are being 
used, that public key is rather large for sending with every request 
when even a fingerprint of the key would suffice to identify it.


From my reading of the spec, there isn't a way for a server that wants 
to remember the public key in backend session state to optimize the proof.


Thanks,
George___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token Revocation error codes

[George Fletcher]

 perspective we can't say that the token should
have some structure: they can be any random value in case of
reference (opaque) tokens. But the Google's OAuth Server
responds in this case with 400 error "invalid_token".
>> The same can be used for JWTs with invalid sign or issuer.
>> So it would be better if specification allow OAuth servers
to respond with this error code if it clearly know that token
was invalid by format.
>>
>> On Tue, 22 May 2018 at 17:51, Thomas Broyer
 wrote:
>>>
>>> IFF the server processes it!
>>> RFC 7009 says “An authorization server MAY ignore this
parameter, particularly if it is able to detect the token type
automatically.” which BTW is exactly my case.
>>>
>>> For months, my AS received requests with token=Array, and
now receives requests with token=null. Those are clearly bugs
in the client code, and because I return a 200 OK, the
developers aren't aware of it.
>>>
>>> If tokens have an expected "structure", I think AS should
probably return an error when the token value clearly is not a
token (at one point I may change my implementation to do just
that). As soon as it looks like a potential token though, then
200 OK sounds good to me.
>>>
>>> On Tue, May 22, 2018 at 4:34 PM Justin Richer
 wrote:
>>>>
>>>> In that specific case, the token_type_hint value is
invalid and can be rejected as an invalid_request.
>>>>
>>>>  — Justin
>>>>
>>>>
>>>> On May 22, 2018, at 5:27 AM, Joseph Heenan
 wrote:
>>>>
>>>>
>>>> I think one important point Sergey raised was that the
response to the client from submitting the wrong token is the
same 200 response as submitting a valid token, and that hugely
increases the chance that the developer of the client app
might submit the wrong token and never realise. Making it
easier for the developer of the client app to see that they've
done something wrong and need to fix their implementation
seems like a worthwhile goal to me, and that would appear to
explain what google are thinking with their responses.
>>>>
>>>> An example of an easy to make error that would get a 200
response is getting the values the wrong way around, i.e. a
body of:
>>>>
>>>> token=refresh_token_type_hint=45ghiukldjahdnhzdauz
>>>>
>>>> (as token_type_hint may be ignored by the server.)
>>>>
>>>> The example Sergey gave of the developer accidentally
sending the id token instead of the intended token seems quite
likely to happen in the real world too, and a 200 response in
that case does seem wrong to me.
>>>>
>>>>
>>>> Joseph
>>>>
>>>>
>>>> On 21 May 2018, at 22:29, Justin Richer 
wrote:
>>>>
>>>> I’m with George here: revocation is almost a best-effort
request from the client’s perspective. It sends a message to
the server saying “hey I’m done with this token, you can throw
it out too”. If the server does revoke the token, the client
throws it out. If the server doesn’t revoke the token? Then
the client still throws it out. Either way the results from
the client’s perspective are the same: it’s already decided
that it’s done with the token before it talks to the server.
It’s an optional cleanup step in most  OAuth systems.
>>>>
>>>>  — Justin
>>>>
>>>> On May 21, 2018, at 5:08 PM, George Fletcher
 wrote:
>>>>
>>>> I'm not understanding how these different cases matter to
the client? I doubt that the running code will be able to
dynamically handle the error. So it seems this information is
only relevant to the developers and not relevant from an end
user and the client perspective.
>>>>
>>>> Also, for the 5 states you define, the effect of calling
revocation is still that the token is "revoked" because the
token is already not valid.
>>>>
>>>> So from an implementation per

Re: [OAUTH-WG] Call for adoption - JWK Thumbprint URI

[George Fletcher]

+1 for adoption

On 1/13/22 9:26 AM, Rifaat Shekh-Yusef wrote:

All,

This is a call for adoption for the *JWK Thumbprint URI* draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/

Please, provide your feedback on the mailing list by *Jan 27th*.

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] Virtual office hours

[George Fletcher]

Is there a link to a calendar I can pull into my master calendar? That 
would be really helpful :)


On 1/10/22 8:14 AM, Rifaat Shekh-Yusef wrote:

The virtual office hours are on Wednesday at 12:00pm Eastern Time.

Regards,
 Rifaat


On Mon, Jan 10, 2022 at 1:03 AM Mike Jones 
 wrote:


Are the OAuth virtual hours happening 11 hours from now?

Inquiring minds want to know. ;-)

-- Mike

___
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] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[George Fletcher]

ot match the inexistent
code_challenge/code_challenge_method in the malicious
authorization response.

For this to work, the client must either generate a
code_verifier on the fly or have one already present. This
obviously depends on the precise implementation of the
respective client.

To reach such a state, an attacker could trick the user into
starting the authorization grant but clicking the malicious
link before the authorization response is sent.

Best Regards,

Benjamin Häublein
Senior Consultant

cirosec GmbH
Ferdinand-Braun-Strasse 4
74074 Heilbronn
Germany
Phone: +49 (7131) 59455-74
Fax: +49 (7131) 59455-99
Mobile: +49 (151) 122414-74
www.cirosec.de <http://www.cirosec.de>

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips

*Von:* Warren Parad 
*Gesendet:* Mittwoch, 5. Januar 2022 13:44
    *An:* Benjamin Häublein 
*Cc:* George Fletcher ; oauth@ietf.org
*Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server
Verifies code_verifier facilitates Login-CSRF




Sie erhalten nicht oft E-Mail von "wpa...@rhosys.ch". Weitere
Informationen, warum dies wichtig ist
<http://aka.ms/LearnAboutSenderIdentification>



I'm not following to be honest. Could you detail concretely
what the flow would be that would result in vulnerability?




*Warren Parad*

Founder, CTO

Secure your user data with IAM authorization as a service.
Implement Authress <https://authress.io/>.

On Wed, Jan 5, 2022 at 1:41 PM Benjamin Häublein
 wrote:

Finally, I'm not sure a client that doesn't send the
'code_challenge' and 'code_challenge_method' on the
authorization request but does send the 'code_verifier' on
the token request should consider that the client has
implemented PKCE correctly and hence can rely on it for CSRF.

My point is not, that a client behaves that way. The
problem is that an attacker could get a user (through
social engineering) to start the authorization process and
then click a link with an authorization response that the
attacker provides.

Then the client has send the 'code_challenge' and
'code_challenge_method' in the authorization request, but
the authorization response belongs to an authorization
request that does not have these parameters.

When the client sends the token request based on the
malicious authorization request but with the
‘code_verifier’ for the original authorization request.

When the AS behaves as described the client has no way to
know that an attacker has interfered.

        Best Regards,

Benjamin Häublein

*Von:* George Fletcher 
*Gesendet:* Dienstag, 4. Januar 2022 14:51
*An:* Benjamin Häublein ;
oauth@ietf.org
*Betreff:* Re: [OAUTH-WG] Edge case in RFC 7636, Server
Verifies code_verifier facilitates Login-CSRF

My guess is that for an Authorization Server that doesn't
receive a 'code_challenge' and 'code_challenge_method' as
part of the authorization request, they treat the request
as a non-PKCE authorization request. Therefore when the
'code_verifier' is presented at the /token endpoint, the
AS ignores the parameter because it doesn't consider the
request to be a PKCE request. I can also see the AS
returning an error regarding an "unexpected parameter" or
"invalid request" error in this case.

I agree with your recommendation for the AS to require
specific clients to use PKCE and consider an authorization
request without PKCE to be an error.

Finally, I'm not sure a client that doesn't send the
'code_challenge' and 'code_challenge_method' on the
authorization request but does send the 'code_verifier' on
the token request should consider that the client has
implemented PKCE correctly and hence can rely on it for CSRF.

Thanks,
George

On 1/4/22 5:45 AM, Benjamin Häublein wrote:

Hello everyone,

I think RFC 7636 “Proof Key for Code Exchange by OAuth
Public Clients”, section 4.6. “Server Verifies
code_verifier before Returning the Tokens” leaves a
tiny gap regarding the handling of verification when
no code challenge was present in the au

Re: [OAUTH-WG] Edge case in RFC 7636, Server Verifies code_verifier facilitates Login-CSRF

[George Fletcher]

My guess is that for an Authorization Server that doesn't receive a 
'code_challenge' and 'code_challenge_method' as part of the 
authorization request, they treat the request as a non-PKCE 
authorization request. Therefore when the 'code_verifier' is presented 
at the /token endpoint, the AS ignores the parameter because it doesn't 
consider the request to be a PKCE request. I can also see the AS 
returning an error regarding an "unexpected parameter" or "invalid 
request" error in this case.


I agree with your recommendation for the AS to require specific clients 
to use PKCE and consider an authorization request without PKCE to be an 
error.


Finally, I'm not sure a client that doesn't send the 'code_challenge' 
and 'code_challenge_method' on the authorization request but does send 
the 'code_verifier' on the token request should consider that the client 
has implemented PKCE correctly and hence can rely on it for CSRF.


Thanks,
George


On 1/4/22 5:45 AM, Benjamin Häublein wrote:


Hello everyone,

I think RFC 7636 “Proof Key for Code Exchange by OAuth Public 
Clients”, section 4.6. “Server Verifies code_verifier before Returning 
the Tokens” leaves a tiny gap regarding the handling of verification 
when no code challenge was present in the authorization request:


Upon receipt of the request at the token endpoint, the server

verifies it by calculating the code challenge from the received

"code_verifier" and comparing it with the previously associated

"code_challenge", after first transforming it according to the

"code_challenge_method" method specified by the client.

It is unspecified how the server should behave when “code_verifier” is 
present, but “code_challenge” and “code_challenge_method” were not set 
in the initial authorization request.


The following example worked for three well-known authorization 
servers where the client was configured in a way that PKCE could be 
used, but was not enforced:


Authorization Request:

https:///auth?client_id=_type=code=openid+profile_uri=https://localhost 



Subsequent Token Request:

POST /token HTTP/1.1
Host: 
Content-Length: 256

code=_type=authorization_code_id=_uri=https%3A%2F%2Flocalhost_verifier=IqiCQGM06JEyW73AB3f3oblCQKHOorapyqHUcYRujuSikDJx8cvBQ0kmFmzW75uIfaSBtXQrRmwuk71WWO6ryCzahTcxBPYX

As a result, an access token was issued although the code_verifier 
provided in the token request did not match the code_challenge and 
code_challenge_method in the authorization request.


Many applications consider the usage of PKCE as enough protection from 
Login-CSRF and do not use state or nonce (for example this blog entry 
by Daniel Fett 
https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/ 
suggests, that neither state nor nonce are necessary when PKCE is 
used). However, when the authorization server is not configured to 
require a specific code_challenge_method from the client and the 
authorization behaves as described in the example, PKCE does not 
protect from Login-CSRF.


I think the following mitigations are possible:

  * Enforce usage of PKCE in the client configuration in the
Authorization Server
  * Implementation of the authorization server returns an error in the
Access Token Response when code_verifier is present in the token
request, but no code_challenge and code_challenge_method is
present in the authorization request.
  * Additionally, when the behavior of an AS is correct (verification
of code_verifier fails when no code_challenge was present), a
client that relies on PKCE for CSRF protection must always include
a code_verifier parameter in the token request (even if no
code_verifier is present on the client side).

Best regards,

Benjamin Häublein
Senior Consultant

cirosec GmbH
Ferdinand-Braun-Strasse 4
74074 Heilbronn
Germany
Phone: +49 (7131) 59455-74
Fax: +49 (7131) 59455-99
Mobile: +49 (151) 122414-74
www.cirosec.de

HRB Stuttgart 107883
CEO Stefan Strobel, CFO Peter Lips


___
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] [EXTERNAL] Re: OAuth Redirection Attacks

[George Fletcher]

Given the attack is based on a successfully registered callback URL that 
is malicious, we can also look to the Authorization Server to run more 
checks on the registered callback URLs (e.g. check against the "unsafe" 
URL list). Not a 100% solution by any means but could help with reduce 
the impact. Additionally, making sure the AS can easily revoke any 
client_id and have that take effect quickly.


Another potential option would be to not allow prompt=none (or automatic 
redirects) from contexts where the user hasn't first gone through a full 
authentication flow or at least allow the AS to display UI at it's 
discretion. Though this will definitely break some flows :(


This at least illuminates one of the dangers of allowing a wide open 
dynamic client registration model :)


Thanks,
George

On 12/18/21 1:11 AM, David Waite wrote:



On Dec 17, 2021, at 2:44 PM, Brian Campbell 
 wrote:

Relax how aggressively OAuth demands that the AS automatically redirect in 
error conditions. And either respond with a 400 directly (which just stops 
things at that point) or provide a meaningful interstitial page to the user 
before redirecting them (which at least helps users see something is amiss). I 
do think OAuth is a bit overzealous in automatically returning the user's 
browser context to the client in error conditions. There are some situations 
(like prompt=none) that rely on the behavior but in most cases it isn't 
necessary or helpful and can be problematic.

The problem is that if prompt=none still requires redirection without prompt or 
interstitial, someone wishing to treat dynamic registrations of malicious sites as 
clients will just start using prompt=none. Likewise, a site could still attempt to 
manipulate the user to release information by imitating an extension to the 
authentication process, such as an "expired password change" prompt.

I agree with Nov Matake's comment - phishing link email filters should treat 
all OAuth URLs as suspect, as OAuth has several security-recommended features 
like state and PKCE which do not work as expected/reliably with email. Filters 
integrated into the browser (such as based on the unsafe site list in Chrome) 
should not need changes, as they will warn on redirect to the known malicious 
site.

We should also continue to push as an industry for authentication technologies 
like WebAuthn (as well as mutual TLS and Kerberos) which are phishing 
resistant. We are really talking about failure of a single phishing mitigation 
for _known_ malicious sites - the opportunity to use any unknown malicious site 
or a compromised legitimate site remains open even if we do suggest changes to 
error behavior.

-DW

___
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 - OAuth Proof of Possession Tokens with HTTP Message Signatures

[George Fletcher]

Just curious where this landed? Was it adopted by the WG? I'm ok with 
adopting it. We will just need to be clear about the overlap with DPoP 
and determine if guidance is necessary for when to use which method.


Thanks,
George

On 7/30/21 3:26 PM, Aaron Parecki wrote:
I support the adoption of this document, it seems like a good starting 
point for defining the link between HTTP Signatures and OAuth.


Aaron


On Mon, Jul 19, 2021 at 7:18 AM Justin Richer > wrote:


Needless to say, but as the author of both this draft and the
draft that it would replace, I am in favor of adoption of this
document. There are still a lot of open questions to answer — such
as key introduction and management practices — and I think there
is a lot of power in the intersection of the OAuth and HTTPSig
spaces.

 — Justin


On Jul 16, 2021, at 12:31 PM, Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> wrote:

All,

This is a call for adoption for the *OAuth Proof of Possession
Tokens with HTTP Message Signatures* draft as a WG document:
https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/


Please, provide your feedback on the mailing list *by July 30th*.

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


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

Re: [OAUTH-WG] Purpose of client authentication for "public" client types

[George Fletcher]

While not widely deployed, the OAuth2 solution to a deployment of 
"public clients" that need to be able to transition to "confidential 
clients" so that client authentication makes sense, is to use Dynamic 
Client Registration (RFC 7591).


Dynamic Client Registration allows the public client to register and 
obtain (or provide) a client secret that is unique to that instance of 
the app. At that point, the client can authenticate to the backend 
services as needed. This model increases the security of the solution 
and decreases the risk while also providing a stepping stone to moving 
away from Bearer tokens to proof-of-possession model for tokens.


General best practice is to have the public client create a 
public/private key pair and register the public key as part of the 
registration event. The client can then prove its authenticity by 
signing data with the private key and the backend can validate via the 
public key. In the case of many mobile platforms, the public/private key 
pair can be created in the secure enclave of the device adding 
additional security protection for the private key.


As for risk with the deployment mechanisms used by the API Gateways, 
there is really no additional risk and no additional security benefit 
for providing the secret in the public client. Both clients can be 
easily impersonated so the gateway MUST treat a client secret coming 
from a public client with the exact same risk measurement as a request 
coming from a public client without the client secret. Basically, the 
risk/security is the same. There may, however, be backend developer 
benefit by keeping the flows more similar.


Thanks,
George

On 8/25/21 9:59 AM, STAS Thibault wrote:


Dear,

I notice that many API Gateway providers are requiring the 
authentication of the client, even for public client types.


e.g.

https://docs.apigee.com/api-platform/security/oauth/implementing-password-grant-type 



https://auth0.com/docs/flows/call-your-api-using-resource-owner-password-flow 



https://tyk.io/docs/basic-config-and-security/security/authentication-authorization/oauth2-0/username-password-grant/ 



Not many providers are make the use of the client authentication 
optional, as the client_secret is always present in either the 
Authorization Basic header or within the payload.


What is the added value to perform client application authentication 
in the context of �public� client type, like a vendor application sold 
to many customers�?


The client_secret would be shipped along with the application, putting 
at risk the secrecy of the client_secret.


The oAuth standard does not seem to provide a lot of guidance with 
regards to the use and need of the client authentication in such context.


Would it not be preferable to recommend client identification rather 
than client authentication in combination with resource-owner 
authentication ?


The client_id could be provided as part of the selected grant type 
parameters.


Kind regards,

**

*Thibault STAS *

SWIFT | Enterprise Architect � Information Technology

Tel: + 32 2 655 4975


www.swift.com 

This e-mail and any attachments thereto may contain information which 
is confidential and/or proprietary and�intended for the sole use of 
the recipient(s) named above. If you have received this e-mail in 
error, please immediately notify the sender and delete the mail.� 
Thank you for your co-operation.� SWIFT reserves the right to retain 
e-mail messages on its systems and, under circumstances permitted by 
applicable law, to monitor and intercept e-mail messages to and from 
its systems.



___
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] DPoP key rotation

[George Fletcher]

There has also been some limited discussion on whether it's useful for 
mobile applications to create a relationship between keys used for 
Dynamic Client Registration (DCR) and the associated keys for DPoP 
headers. DCR does have mechanisms for rotating client instance keys and 
hence if the keys for DPoP are the same then this might be a mechanisms 
to support rotation for mobile applications.


Note that while both Android and iOS have hardware support for keys... 
the keys themselves have limitations on how they can be used, so 
depending on your use case, the hardware backed keys may not suffice.


Thanks,
George

On 6/11/21 4:20 PM, Brian Campbell wrote:

Hi Dmitry,

This ML is indeed the appropriate place for this kind of thing. You 
raise a legitimate question, however, the general rough consensus 
thinking has been that allowing for DPoP key rotation for refresh 
tokens and public clients (the only case where it's relevant) didn't 
add enough value to justify the added complexity. It doesn't help with 
the threat model for in-browser applications. And mobile applications 
have really good options for key storage - to the point that the kind 
of event that might compromise a DPoP key would involve a lot more 
than key rotation to cleanup from.




On Tue, Jun 8, 2021 at 10:31 AM Dmitry Telegin 
> wrote:


Hi,

I'm Dmitry Telegin, I'm currently working on DPoP implementation
in Keycloak on behalf of my company, Backbase. Takashi Norimatsu
of Hitachi supervises this process as the head of the Keycloak
FAPI SIG.

With the current DPoP design, once the keypair has been generated
on the user agent and the initial token set has been obtained
(using authorization_code grant), the whole chain of the
subsequent access/refresh tokens will be bound to this particular
keypair. That means, the keypair should be persisted on the user
agent for the duration of the session.

OTOH, sessions could be rather long-lived, especially if we take
offline tokens [1] into account. In a nutshell, offline access
provides a non-expiring refresh token. This could be highly
relevant e.g. for mobile applications that would employ offline
tokens to help users avoid logging in every time.

The longer the session lasts, the higher the probability of key
leakage is. Currently, the only way to switch to a new DPoP
keypair is to start a new session (i.e. log in again). Do you
think it might be worth incorporating some sort of key rotation
concept into DPoP design?

The most obvious way to perform key rotation is to do that during
token refresh. For that, we could make the refresh_token grant
honour the additional DPoP proof that would supersede the current
one. From the technical PoV, it could be as easy as supplying two
proofs within the DPoP header:

|DPoP: eyJ0eXAiO... eyJ0eXAiO... |

|Or we can go with a single (old) DPoP proof, containing the new
proof (to supersede the current one) as a claim (or vice versa). |

|We'd appreciate any feedback from the WG. Also apologize if this
ML is not the appropriate place to discuss issues like this. |

|Regards, |

|Dmitry Telegin |

|Senior Backend Engineer, Backbase R B.V. |

[1]
https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

___
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] I-D Action: draft-ietf-oauth-security-topics-17.txt

[George Fletcher]

While this is mostly covered in section 8.6 of RFC 8252 for native apps, 
I wonder if we shouldn't mention "Client Impersonation" in this doc as 
well in that any public client can be easily impersonated. Mobile OS's 
are providing additional mechanisms for "authenticating" the client but 
it's unclear whether those will be made available in desktop 
environments where native apps also exist. At this stage Universal Links 
(iOS) and App Links (Android) should be best practice for any mobile 
native app. Best practice for desktop apps is less clear.


Impersonating a public client is very easy especially if the only 
mechanism available for the callback is a custom scheme URL.


Thoughts?

On 4/6/21 9:15 AM, Daniel Fett wrote:

Hi all,

this version most importantly updates the recommendations for Mix-Up 
mitigation, building upon 
https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The 
description of Mix-Up attacks has also been improved.


Smaller changes:

   * Make the use of metadata RECOMMENDED for both servers and clients
   * Make announcing PKCE support in metadata the RECOMMENDED way 
(before: either metadata or deployment-specific way)

   * AS also MUST NOT expose open redirectors.
   * Mention that attackers can collaborate.
   * Make HTTPS mandatory for most redirect URIs.

I'll present more details in the interim meeting next monday.

As always, your feedback is appreciated. We hope that we can proceed 
to a WGLC for this document soon.


-Daniel

Am 06.04.21 um 15:06 schrieb internet-dra...@ietf.org:

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 Security Best Current Practice
 Authors : Torsten Lodderstedt
   John Bradley
   Andrey Labunets
   Daniel Fett
Filename: draft-ietf-oauth-security-topics-17.txt
Pages   : 52
Date: 2021-04-06

Abstract:
This document describes best current security practice for OAuth 2.0.
It updates and extends the OAuth 2.0 Security Threat Model to
incorporate practical experiences gathered since OAuth 2.0 was
published and covers new threats relevant due to the broader
application of OAuth 2.0.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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



--
https://danielfett.de

___
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] Authorization handover from mobile app to website

[George Fletcher]

privileges for this user SHOULD be 
restricted and require additional authentication checks.
Possible mitiations include...


One way to manage the authentication session is to track the 
  time at which the user last presented authentication 
  credentials (e.g. password). By tracking this within the 
  session context any web-application can protect certain 
  privileges by requiring the user to have presented their 
  credentials within the last n seconds/minutes. For a web 
  session created via this flow, the authentication credentials 
  presentation time is the time at which the user authenticated 
  to create the refresh_token.

The Authorization Server SHOULD revoke any existing web session
  if the refresh_token used to create the web session is revoked.

Any additional tokens issued from the web session MUST be
  linked to the refresh_token that created the web session such that
  if the refresh_token is revoked or expired, the generated access
  tokens are revoked/expired accordingly.

The Authorization Server SHOULD provide an interface for the user
  that shows the active web sessions issued from refresh tokens
  and allow the user to expire the web session.


 


   


 TOC 
5. Normative References

[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC6749]
Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
[RFC6750]
Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).



 TOC 
Author's Address

 
George Fletcher (editor)
 
AOL Inc.
Email: 
gffle...@aol.com


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

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[George Fletcher]

Unfortunately, in the mobile app world this isn't sufficient. On iOS 
using Universal Links will bind the https redirect_url to your app in a 
secure way but it doesn't work the same way on Android with App Links. 
There is still a problem with "mobile app impersonation". If you have an 
app that you want to ensure is "your" app then the most secure way is to 
look at "app attestation". This is however, way off topic for this thread :)


On 2/14/21 9:28 AM, Neil Madden wrote:

Public clients are implicitly authenticated by their ownership of the 
registered redirect_uri. This why it’s important to use a redirect_uri for 
which ownership can be reasonably established, such as HTTPS endpoints with 
exact URI matching.

There are more things that can go wrong with that (see the security BCP), but 
it can be made reasonably secure.

— Neil


On 14 Feb 2021, at 13:48, Stoycho Sleptsov  wrote:


I would like to add my reasons about the "Why are developers creating BFF for their 
frontends to communicate with an AS",
with the objective to verify if they are valid.

I need the client app. to be authenticated at the AS (to determine if it is a 
first-party app., for example).
If we decide to implement our client as a frontend SPA , then we have no other 
option except through a BFF, as PKCE does not help for authentication.

Or is it considered a bad practice to do that?

Regards,
Stoycho.
___
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] Your opinion about draft-ideskog-assisted-token

[George Fletcher]

Hi Adrian,

I agree with Brian that the proposed document directly relates to 
ongoing work in the OAuth working group. Establishing a completely 
different mechanism for supporting Single Page Apps other than what is 
being proposed by the working group will lead to bifurcated 
implementations and potential confusion across the industry. I'd much 
prefer to see the work proposed to be considered for adoption by the 
OAuth working group such that it can go through the normal 
standardization process. This will also ensure that the security best 
practices document will cover any additional mechanisms and keep all 
that work together.


Thanks,
George

On 2/19/21 4:09 PM, Brian Campbell wrote:

Hi Adrian,

I believe this work was presented briefly to the WG in London during 
IETF 101. As far as I can recall, the general reaction/thinking at 
that time was that the WG really should be working on a document about 
OAuth and single page applications (that may or may not include 
something like the functionality in draft-ideskog-assisted-token). 
Since that time the WG adopted and is actively working on 'OAuth 2.0 
for Browser-Based Apps' 
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ 
 
which is intended as a BCP for single page applications acting as 
OAuth clients. The prospective BCP details security considerations and 
best practices around leveraging existing features of OAuth for single 
page apps. Whereas draft-ideskog-assisted-token introduces a new 
grant, new authorization server endpoint, and really a whole new 
interaction model between client and authorization server. Publishing 
an independent stream RFC that runs contrary to the BCP coming out of 
the WG does seem potentially harmful.





On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) 
mailto:rfc-...@rfc-editor.org>> wrote:


Hi OAuth,

The authors of draft-ideskog-assisted-token [1] have approached me
requesting that the draft be published as an Informational RFC in the
Independent Submission Stream [2].

The draft extends the OAuth 2.0 framework to include an additional
authorization flow for single page applications called the
assisted token
flow. It is intended to enable OAuth clients that are written in
scripting languages (such as JavaScript) to request user authorization
using a simplified method. Communication leverages HTML's iframe
element,
child windows, and the postMessage interface. This communication
is done
using an additional endpoint, the assisted token endpoint.

It is clear to me that this work could be in scope for OAuth and I
want to
be sure that both:
- there is no interest within the WG in pursuing this approach
- there is no perceived harm to existing OAuth work if this goes ahead

I'd appreciate any opinions.

Many thanks,
Adrian
--
Adrian Farrel (Independent Submissions Editor),
rfc-...@rfc-editor.org 

[1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/

[2] https://www.rfc-editor.org/about/independent/

>
>


-- 
Adrian Farrel (ISE),

rfc-...@rfc-editor.org 

___
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] Android App Links (AKA Universal Links)

[George Fletcher]

The focus of the IIW session was "Mobile App Impersonation" and what can 
be done about it. Obviously moving to Universal Links (iOS) and App 
Links (Android) is an important first step but not sufficient on Android 
as you point out. Other areas of exploration are around dynamic client 
registration (forces the app impersonator to call a specific endpoint 
which can increase the ability to detect the impersonation). Also 
possibly combining device attestation and app attestation into the mix 
could provide a mechanism to ensure only the intended apps can get 
access. However, this is a fair amount of work for developers to prevent 
app impersonation. There is a big question regarding ROI of closing this 
attack vector:)


I'm especially interested in whether anyone has even looked at their 
logs and tried to detect app impersonation of their public clients. Feel 
free to message me privately if you don't want to share with the group :)


Thanks,
George

On 11/4/20 7:29 AM, Joseph Heenan wrote:

Thanks George :) That’s a shame, I would have liked to listen to the recording.

My email below was thinking of the OSW interactive sessions (we had about 2 
hours of technical discussion on some of the issues with implementing app2app 
in practice particularly on Android), but now I’ve looked I think perhaps the 
recordings of those weren’t published. I have been working on a blog post with 
others that delves more into the Android side of things, hopefully we will 
publish that in the not too distant future.

I did an identiverse session too, which although it starts out quite similar 
diverges after about 10 minutes, delving less into the detail of security and 
covering more of the higher level what/why/how: 
https://identiverse.gallery.video/detail/video/6186099813001/

Joseph


On 3 Nov 2020, at 22:12, George Fletcher  wrote:

I sent in some notes but I don't have a link for the recording. I don't believe 
the recordings were being kept much past the end of the conference. I'm pretty 
sure I heard that the recordings would be removed after N days (I don't 
remember what N was stated as:)

Joseph explanation is better than I could have given and matches my 
understanding as well.

Thanks,
George

On 11/3/20 2:13 PM, Dick Hardt wrote:

Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  
<mailto:jos...@authlete.com> wrote:


Hi Dick

I didn’t attend the call so don’t know the background of this and the
exact situation, but the general problem is mostly where the Authorization
Server’s app is *not* installed. In that case Android falls back to much
weaker mechanisms that allow other apps to get a look in. App links also
aren’t consistently supported across all commonly used android browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it’s
necessary for both apps to fetch the /.well-known/assetlinks.json for the
url they want to redirect to, and verify that the intent the app intends to
launch to handle the url is signed using the expected certificate. Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt  
<mailto:dick.ha...@gmail.com> wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links 
<https://developer.android.com/training/app-links>

An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

/Dick
ᐧ
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth 
<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] Android App Links (AKA Universal Links)

[George Fletcher]

I sent in some notes but I don't have a link for the recording. I don't 
believe the recordings were being kept much past the end of the 
conference. I'm pretty sure I heard that the recordings would be removed 
after N days (I don't remember what N was stated as:)


Joseph explanation is better than I could have given and matches my 
understanding as well.


Thanks,
George

On 11/3/20 2:13 PM, Dick Hardt wrote:

Thanks Joseph.

George Fletcher ran a great session on the topic at the last IIW as well.

George: do you have a link?

ᐧ

On Tue, Nov 3, 2020 at 11:09 AM Joseph Heenan  wrote:


Hi Dick

I didn’t attend the call so don’t know the background of this and the
exact situation, but the general problem is mostly where the Authorization
Server’s app is *not* installed. In that case Android falls back to much
weaker mechanisms that allow other apps to get a look in. App links also
aren’t consistently supported across all commonly used android browsers
which causes further problems.

In general to do app2app oauth redirections securely on Android it’s
necessary for both apps to fetch the /.well-known/assetlinks.json for the
url they want to redirect to, and verify that the intent the app intends to
launch to handle the url is signed using the expected certificate. Web2app
flows are trickier, on both iOS and on Android. There were lengthy
discussions on at least the Android case at OAuth Security Workshop this
year (recordings available).

Joseph


On 20 Oct 2020, at 00:09, Dick Hardt  wrote:

Hey Vittorio

(cc'ing OAuth list as this was brought up in the office hours today)

https://developer.android.com/training/app-links

An app is the default handler and the developer has verified ownership of
the HTTPS URL. While a user can override the app being the default handler
in the system settings -- I don't see how a malicious app can be the
default setting.

What am I missing?

/Dick
ᐧ
___
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] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[George Fletcher]

The issue I see with sticking with the DPoP token_type is that from a 
roll_out perspective, ALL resource servers must be updated to support 
the new scheme and only then can the DPoP deployment start. For any wide 
ecosystem deployment that can be problematic. I don't have any great 
suggestions:(


Secondly, I do think we need a way to allow for the refresh_token to be 
bound while leaving the access_tokens as bearer tokens. This adds useful 
security without impacting existing RS deployments. It was unclear from 
our interim meeting discussion how the client knows whether the refresh 
token has been bound to the public key or not. The AS can signal that 
the access_token is NOT bound by returning a token_type of "bearer" but 
we should think about adding addition response fields for the refresh 
token binding (e.g. "rt_token_type).


Thanks,
George

On 5/29/20 5:50 PM, Brian Campbell wrote:
Apologies for the slow reply on this. No excuses other than life  > sometimes happens. > > `token_type` is maybe not the clearest 
extension point (and one I've > arguably misused in OAuth MTLS > 
 and the now defunct > 
Token Binding > 
and > 
admitted to being on the fence about in the issue you linked to > 
). But it is the > 
extension point that was basically left in RFC 6749 to facilitate > this 
exact kind of thing (for MAC really but it's conceptually > similar in 
that it was an application level proof mechanism of sorts) > . The text 
from RFC 6749 sec 7.1 > 
 is also copied > 
below. Note that a "client MUST NOT use an access token if it does > not 
understand the token type" so FWIW the client behaviours you > describe 
aren't in line with that. > > It still seems to be that using DPoP 
token_type is the appropriate > thing to do and that it can be defined 
to account and allow for mixed > token type situations. It would define 
that the DPoP authz scheme be > used as the authentication method to 
include the access token when > making a protected resource request. 
That definition can also include > falling back to using the Bearer 
authz scheme when/if so challenged > by a protected resource. > > 
 > > 7.1 
. Access Token > Types 
> > The access token type provides the client with the information > 
required to successfully utilize the access token to make a > protected 
resource request (along with type-specific attributes). > The client 
MUST NOT use an access token if it does not understand the > token type. 
> > For example, the "bearer" token type defined in [RFC6750 > 
] is utilized by simply > including 
the access token string in the request: > > GET /resource/1 HTTP/1.1 
Host: example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the 
"mac" token type defined in [OAuth-HTTP-MAC > 
] is > utilized 
by issuing a Message Authentication Code (MAC) key together > with the 
access token that is used to sign certain components of the > HTTP 
requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: 
MAC > id="h480djs93hd8", nonce="274312:dj83hs9s", > 
mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" > > The above examples are provided 
for illustration purposes only. > Developers are advised to consult the 
[RFC6750 > ] and [OAuth-HTTP-MAC > 
] > 
specifications before use. > > Each access token type definition 
specifies the additional > attributes (if any) sent to the client 
together with the > "access_token" response parameter. It also defines 
the HTTP > authentication method used to include the access token when 
making a > protected resource request. > > > > On Tue, May 19, 2020 at 
7:20 AM Filip Skokan  > wrote: > >> This is a RE: to 
yesterday's interim meeting discussion, largely >> related to the first 
rollout step where we want to constrain >> refresh tokens but leave 
protected resource access intact. >> >> I'll start off with a case that 
I hope we can agree is absolutely >> necessary for DPoP to solve - that 
is constraining refresh tokens >> for browser based applications. Now, 
*do we see this as a >> secondary objective? I think it should be on par 
with access token >> constraining.* SPAs using code flow and having 
access to refresh >> tokens as means against the continuous browser 
efforts to cut down >> on storage access is a real case servers will be 
eventually forced >> to adopt. >> >> Since rollout for DPoP needs to 
begin with the AS and Client >> supporting it (regardless what order i 
guess) there are going to be >> instances where the RS will be 
supporting both Bearer and 

Re: [OAUTH-WG] Caution about open redirectors using the state parameter

[George Fletcher]

+1

However, we should be careful how we prohibit it... because if the state 
value is actually signed, having the URL there isn't a problem as the 
attacker can not manipulate the value without breaking the signature.


On 4/20/20 5:28 PM, Mike Jones wrote:

I've seen several circumstances where "clever" clients implement an open 
redirector by encoding a URL to redirect to in the state parameter value.  Attackers can 
then utilize this open redirector by choosing a state value.

Can we please add an explicit prohibition of this practice in 
draft-ietf-oauth-security-topics?

Thanks,
-- Mike



___
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] DPoP - new authorization scheme / immediate usability concerns

[George Fletcher]

This brings up interesting rollout questions. Protecting just the 
refresh_token is easy and a useful security measure (especially if 
access tokens are short lived). However, once you start issuing DPoP 
bound access tokens to a client, it means ALL the endpoints that client 
invokes MUST understand DPoP and know what to do with the header. 
Depending on how many endpoints that is, spread across N teams (or even 
companies) this can be problematic.


As much as I agree with Justin in regards to the security issues, it may 
not be possible to force all RPs to update at the same time. This is of 
course potentially solvable if the client uses unique access tokens per 
API endpoint AND the AS knows which endpoints support DPoP and which 
don't. The problem here is that this creates a tight-coupling between RP 
and AS (at least for the rollout period).


On 4/17/20 11:25 AM, Filip Skokan wrote:

I completely agree Justin, as mentioned - i wondered a year ago, I don't
anymore. But i'd like it to be clear that sending a DPoP proof does not
necessarily mean the AS MUST issue a DPoP access token. Depending on the
AS/RS relationship and configuration a regular Bearer may be still be
issued and only the public client's refresh token would be constrained.

Best,
*Filip*


On Fri, 17 Apr 2020 at 17:16, Justin Richer  wrote:


The idea of “Continuing to work without taking advantage of sender
constraints” is, I would argue, a security hole. Systems are allowed to
fail security checks but still offer functionality. This is exactly the
pattern behind allowing an unsigned JWT because you checked the “alg"
header and it was “none” and so you’re OK with that. Yes, you shouldn’t do
that, but maybe we could’ve also made this more explicit within JOSE. By
using the ‘DPoP’ auth scheme, we’re making a clear syntactic change that
says to the RS “either you know to look for this or you don’t know what it
is”.

It’s one of the problems I have with how the OAuth MTLS spec was written.
By re-using the “Bearer” scheme there, I believe we’ve made a mistake that
allows things to fall through in an insecure fashion. The same argument
against it — ease of porting existing deployments — was raised there as
well, and it won in the end. I hope we can do better this time.

  — Justin

On Apr 16, 2020, at 4:05 AM, Filip Skokan  wrote:

I'm still somewhat on the fence as to the pros and cons of using a new

token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?


If we had stuck "bearer" than i wouldn't have raised this topic, since
existing RS would most likely ignore the cnf claim and the resource server
calls would continue to work, obviously without taking advantage of the
available sender check.

As I wrote the preceding rambling paragraph I am starting to think that

more should be said in the draft about working with RSs that don't support
DPoP. Which isn't really what you were asking about. But maybe would cover
some of the same ground.


I agree.

  The AS is the one that does the binding (which includes checking the

proof) so I don't see how sending two proofs would really work or help the
situation?


:facepalm: indeed, sorry.

S pozdravem,
*Filip Skokan*


On Tue, 14 Apr 2020 at 23:39, Brian Campbell 
wrote:


Hi Filip,

My attempts at responses to your questions/comments are inline:

On Tue, Apr 14, 2020 at 2:14 AM Filip Skokan  wrote:


I've wondered about the decision to use a new scheme before
 but
this time i'd like to challenge the immediate usability of the future spec
for one specific case - sender constraining public client Refresh Tokens.


I'm still somewhat on the fence as to the pros and cons of using a new
token type and authorization scheme. But the draft has gone with a new one.
Would it have really helped this situation, if it'd stuck with "bearer"? Or
would it just be less obvious?



If at all, it is going to take time for RS implementations to recognize
the new `DPoP` authorization scheme, let alone process it properly. In the
meantime, i'd still like to have the option to bind issued public client
refresh tokens using DPoP without affecting the access tokens. In doing so
i get an immediate win in sender constraining the refresh tokens but not
introducing a breaking change for the RS.


- Do you see this as something an AS implementation is just free to
do since it's both the issuer and recipient of a refresh token?

That's my first thought, yes.



- Should this be somehow baked in the draft?

I'm not sure. Do you think it needs to be? I'm not sure what it would

say though.

In such a case the AS could bind the RT to the given dpop proof and
either not bind the AT while returning token_type=Bearer or bind the AT
while returning token_type value DPoP. In the latter case the AT would
almost 

Re: [OAUTH-WG] PAR and client metadata

[George Fletcher]

I don't know about a PAR "requirement", but it feels like the PAR spec 
is the right place to put this. My understanding of what's being asked 
is... how does the AS advertise to it's clients that it will ONLY accept 
PAR based request_uris and other authn/authz request methods will fail.


On 4/17/20 3:22 AM, Torsten Lodderstedt wrote:

Is this really a PAR requirement? I’m asking since the client in the end is 
required to use an authorization request in the fron channel but with a PAR 
request_uri. So one could see this as a constrained on the authorisation 
request itself. Another question is whether this request_uri must be PAR based 
or whether it could be any other request_uri.


On 16. Apr 2020, at 23:05, George Fletcher  
wrote:

Maybe if we make it an array of authorization "flows" supported? A bit like the AS can describe 
whether it supports "pairwise", "public" or both?

Not sure what to name it though:) Possible values could be "redirect" and "par" 
(redirect not being quite right:) which allows for expansion in the future. That way the AS could 
easily signal whether it supports both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.

On 4/16/20 4:50 PM, Brian Campbell wrote:

But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?

___
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] PAR and client metadata

[George Fletcher]

Maybe if we make it an array of authorization "flows" supported? A bit 
like the AS can describe whether it supports "pairwise", "public" or both?


Not sure what to name it though:) Possible values could be "redirect" 
and "par" (redirect not being quite right:) which allows for expansion 
in the future. That way the AS could easily signal whether it supports 
both or just one. It does mean the discovery doc is redundant in 
specifying that the AS supports PAR but that's probably ok.


On 4/16/20 4:50 PM, Brian Campbell wrote:

But do you think that an AS-wide policy
signal (i.e. all_yall_clients_gotta_do_par_every_darn_time : true) is
needed or sufficiently useful?


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

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[George Fletcher]

Hi Denis,

If the same token is used (within a session) for multiple API calls then 
all those API calls can be correlated together even if the token does 
not have a 'sub' claim because the token itself is the correlating 
identifier (same is true for the session identifier).


In regards to the AS issuing a token with a 'sub' claim, after 
re-reading the spec (rfc 7519) I believe the AS could issue the 'sub' 
value as "urn:anonymous:" and create a new value 
with every token that is issued. This is similar to how Shibboleth 
supports attribute based access control with SAML assertions. Given it 
appears we disagree in our interpretations of the spec, I'm fine 
agreeing to disagree :)


Thanks,
George

On 4/14/20 11:23 AM, Denis wrote:

George,

I disagree with you:

   The 'sub' claim must be unique (local to the issuer or globally)
   with every issued token.

In addition, inter-API correlation prevention does not necessarily 
require a unique token for every API call,
since in many cases a session can be opened and one JWT can be used 
during the whole session (during successive calls).


Denis




On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally 
unique in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents 
the solution Vittorio suggested. While for any token issued the 'sub' 
claim must be unique (local to the issuer or globally); that doesn't 
mean it can't be different with every issued token. This would 
require the client to request a new token before every API invocation 
but it would suffice to protect against the suggested privacy 
correlation issues.


Note that inter-API correlation prevention is VERY difficult and 
really requires a unique token for every API call as the token itself 
can be a correlation handle (e.g. hash the token and it becomes the 
correlation identifier if the token is being reused for multiple API 
calls).


Thanks,
George



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

Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[George Fletcher]

On 4/14/20 10:23 AM, Denis wrote:

Unfortunately, this is not possible since RFC 7519 (4.1.2) states:

    The subject value MUST either be scoped to be *locally unique 
in the context of the issuer or be globally unique*.
Regarding this phrase from RFC 7519, I don't agree that it prevents the 
solution Vittorio suggested. While for any token issued the 'sub' claim 
must be unique (local to the issuer or globally); that doesn't mean it 
can't be different with every issued token. This would require the 
client to request a new token before every API invocation but it would 
suffice to protect against the suggested privacy correlation issues.


Note that inter-API correlation prevention is VERY difficult and really 
requires a unique token for every API call as the token itself can be a 
correlation handle (e.g. hash the token and it becomes the correlation 
identifier if the token is being reused for multiple API calls).


Thanks,
George

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

Re: [OAUTH-WG] oauth-browser-based-apps-05 - BFF

[George Fletcher]

Sorry to have missed the meeting.

To your second point, I think we should provide guidance in this area. 
Currently section 6.2 requires all requests to be proxied via the 
application server. Should we add an additional section for the use case 
Vittorio mentions?


Also there is no mention of DPoP (which of course is a draft) but if the 
private key is stored in the secure enclave of the browser/device and 
all requests to the Authorization server and Resource server are signed, 
is that not strong protection of the access_token/refresh_token? Even if 
an attacker can obtain the tokens some how, they would also need to be 
able to run JS to build the appropriate DPoP header in order to use the 
tokens.


Finally, in the cookie models, I don't see any security considerations 
around things like Server Side Request Forgery or logging the cookies. 
As these cookies are all bearer tokens, if they are exposed they can be 
replayed.


On 4/6/20 5:35 PM, Vittorio Bertocci wrote:

Hey Aaron,
Thanks for today�s update on oauth-browser-based-apps, very useful.
As agreed, here�s the summary of the point mentioned during today�s call.


   1.  The last paragraph of 6.2 mentions that an access token could be used as 
session between the JS frontend and its backend, but no details are given about 
the security characteristics of making that choice vs using cookies. I would 
suggest that we either give more guidance on the mechanics of how that would 
happen (how does the AT get delivered to the JS frontend, what attacks 
developers should watch out for, etc) or that we recommend the traditional 
cookie based session approach only.
   2.  Currently 6.2 doesn�t mention topologies where the backend obtains ATs 
and forwards them to the JS frontend, where they are used to perform the actual 
API calls. Those topologies do exist in the wild, and I know there are 
practitioner advocates for that approach on this list too, hence it seems we 
should at least acknowledge those topologies and give some guidance.
If we do position those topologies as legitimate: given that the chatter 
between JS frontend and backend could in some cases reach sophistication 
comparable to the client-AS dialog (token requests, renewals, etc), it seems we 
should either warn people about the security pitfalls they have to watch out 
for (shorter task for us, but not very actionable) or actually invest some time 
in specifying how a JS frontend should talk to its backend to delegate its 
client duties to it and safely retrieve/renew the artifacts the backend obtains 
on the JS frontend�s behalf (much bigger task for us, but unambiguous 
guidance and solid threat model developers can safely rely on).

Thanks!
V.


___
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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

cators in this

 way but is not indicative of the widely deployed models that already 
exist.

 We might have different experiences here. The JWT access tokens from 
popular products I studied in the research I presented in Stuttgart were almost 
all using the aud claim in this way. I am sure that there are other models, and 
there was at least one exception, but in interop terms this seems to be the 
most common way of using JWT for ATs- and it has the advantage of being very 
simple and unambiguous.



 > Section 4. Validating JWT Access Tokens

  �� Step 4. -- Can we change the wording to not require resource

 indicators? What about... "The resource server MUST validate that the

 'aud' claim contains a string that represents the audience of this

 resource server."

 Could you make an example in which you'd want to use an identifier that is not a 
resource indicator? Given that we have the spec, and "audience of the resource 
server" seems to be the exact semantic of resource indicators, it seemed a slam dunk 
to use it here...



> Section 5. "cross-JWT confusion"

  �� I think there may be confusion around what is meant by 
"distinct

 resources". In my example above, are srva.myco.example and

 srvb.myco.example "distinct resources"? or is the goal here to say that

 we want different audience values generated for cross-organization

 resources. For example, are mail.google.com and youtube.com "distinct

 resources"? or would an audience for google suffice in meeting the

 meaning of this paragraph?

 I think the key point here is - we don’t know. I agree the language isn't 
clear there. Let me expand on the intent, and perhaps we can get to a better 
formulation.

 OAuth2 doesn’t demand that RS and AS are run by the same entity, but 
that's the most common scenario. FB doesn't need to specify a resource, because 
the resource is implicit.. it's the FB graph, you can’t get a token for 
anything else. The only differentiator ends up being the scopes. Same for many 
other providers, google, Microsoft for its own Graph, etc.

 However many AS as a service don’t have the benefit of a default, implicit resource, 
especially in multi tenancy scenarios, given that they'll need to issue tokens for a 
number of different recipients. Whether resources are cross organization, or cross 
department, or following any other arbitrary segregation/factoring model is something we 
cannot infer- it's up to the developer to determine that. What I am trying to express 
here is that the operator of the AS as a service (or any other form of "AS for 
rent") should surface resources as a primitive for modeling and identifying intended 
recipients of ATs. Does tis help? How would you express that?



 >  � I'm having the same confusion in the next paragraph regarding 
the

 phrase "different resources". Are services provided by the same company

 "different resources" or are they all considered the same resource. Can

 an access token be issued with scopes for both mail.google.com and

 youtube.com? And if not, why note? Preventing this puts undue burden on

 mobile based applications.

 See preceding point. We can't enter in the merit of what constitutes a 
resource, as that depends on the modeling of the domain specific problem the 
developer is tackling. The highest order bit is that if two entities (API, 
etc.. intended token recipients) have different security characteristics (e.g. 
leaking a token for one has different consequences than if you'd leak a token 
for the other), they should be modeled as different resources. And if they are 
different resources, we should do what we can to avoid confusion in how we 
express access grants to them (hence the big discussion on multiresource, scope 
confusion, etc).





 -

 On 3/24/20, 10:39, "George Fletcher"  wrote:



 Feedback on the spec...



 Section 1. Introduction

  ��� second line: scenario should be plural --> scenarios

  ��� second sentence: "are not ran by" --> "are not run by"



 Section 2.2.1 Authentication Information Claims

  ��� I'm not sure that this definition of `auth_time` allows for 
the

 case where a user is required to solve an additional challenge. Take 
the

 case of a user who is required to pass a secondary challenge before the

 "stock purchase" action can be completed. According to the current spec

 definition, the `auth_time` value MUST NOT be updated when this

 secondary challenge is completed.



  ��� I think there is a difference between session_start_time 
and last

 au

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

If we don't want to give guidance on how the RS determines the correct 
key to use to validate the token, then maybe we should state that 
explicitly. "The mechanism used by the RS to determine the correct key 
to use to validate the access token is out of scope for this specification".


That way at least we are being very clear that the spec is not trying to 
specify how that happens.


Thoughts?

On 3/25/20 2:44 PM, vittorio.berto...@auth0.com wrote:

Brian, there are plenty of ways in which an RS can surprise you with odd 
behavior- for example, developers might see that you used a key for signing an 
IDtoken and use that for init all their validation middleware for ATs as well, 
say because the library only supports one key at a time, and then end up 
failing at runtime when/if the assumption ceases to apply in the future.

Would that be legitimate of them to take such a dependency, even without 
warning text? No. However I am not looking at this from the “lawyering up” 
perspective, but from the useful guidance standpoint as well. I am well aware 
that being concise is a feature, but I am also not crazy about making every 
specification into an intelligence test for the reader. If a 16 words sentence 
can help prevent a likely misstep, I’d be inclined to keep it. But if the 
consensus is that the sentence is confusing, I can also take it out.

  


Brian & George, in the spirit of keeping things simple, and given that this was 
more of a “just in case” warning rather than a security feature clamored for- if 
the language is problematic I’d be more inclined to take the sentence out rather 
than complicating the guidance further.

  


From: Brian Campbell 
Sent: Wednesday, March 25, 2020 11:21 AM
To: George Fletcher 
Cc: Brian Campbell ; Vittorio Bertocci 
; oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens"

  


I don't think you are missing anything, George (except that, to be pedantic, 
`kid` is a header rather than a claim).

  


The question gave me pause, however, and makes me think that maybe the draft, 
with the aim of improved interoperability, should have some more explicit text 
about the use of the 'kid' header in a JWT AT and how it references the 
verification key in the content at the jwks_uri.

  

  

  

  

  


On Wed, Mar 25, 2020 at 11:54 AM George Fletcher mailto:40aol@dmarc.ietf.org> > wrote:

Can we not use the 'kid' claim to inform the RS as to which key is being used? 
What am I missing?

On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.
  
On Wed, Mar 25, 2020 at 10:11 AM 
40auth0@dmarc.ietf.org <mailto:40auth0@dmarc.ietf.org> > wrote:
  


Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").
  
As stated below, the intent wasn’t to prevent substitution/confusion, but

mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.
  
  
  
*From:* Brian Campbell  <mailto:bcampbell=40pingidentity@dmarc.ietf.org> 

*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci  <mailto:vittorio.berto...@auth0.com> 

*Cc:* Richard Backman, Annabelle  <mailto:richa...@amazon.com> 
; oauth <
oauth@ietf.org <mailto:oauth@ietf.org> >
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
  
  
  
I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's

comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..
  
  
  
On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci 
40auth0@dmarc.ietf.org <mailto:40auth0@dmarc.ietf.org> > wrote:
  
*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with

different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*
  
Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they

all can be used for signing. What prevents the AS to use one key from that
list for

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

Can we not use the 'kid' claim to inform the RS as to which key is being 
used? What am I missing?


On 3/25/20 1:51 PM, Brian Campbell wrote:

I think, even without that statement in the draft, that ASes already have
license to use different keys if they so choose. And maybe I'm not creative
enough but I can't think of what problematic assumptions RSes might make
that would prevented by it. So perhaps just removing that whole sentence,
"An authorization server MAY elect to use different keys to sign id_tokens
and JWT access tokens."? Just a thought anyway.

On Wed, Mar 25, 2020 at 10:11 AM  wrote:


Thank you for the perspective- I guessed something similar (“there would
be no way for the RS to know what key is used for what").

As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for
the reasons listed below, or any other reason they might have) and a
headsup to RSes so that they don’t make assumptions.



*From:* Brian Campbell 
*Sent:* Wednesday, March 25, 2020 8:48 AM
*To:* Vittorio Bertocci 
*Cc:* Richard Backman, Annabelle ; oauth <
oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"



I'm gonna go out on a limb and guess/suggest that implicit in Annabelle's
comment was an assumption that signing ATs and ID Tokens with different
keys would be done to prevent token substitution/confusion. And there's not
really a practical way to achieve that with the mechanics of the jwks_uri..



On Wed, Mar 25, 2020 at 3:53 AM Vittorio Bertocci  wrote:

*>§4 p3: The only practical way for the AS to sign ATs and ID Tokens with
different keys is to publish the keys in two different JWK sets. This only
way to do this today is by publishing separate OAuth 2.0 authorization
server metadata and OIDC Discovery metadata files, where the JWK set in the
former applies to access tokens and the JWK set in the latter applies to ID
Tokens.*

Hmm, I don’t follow. The OIDC jwks_uri can contain multiple keys, and they
all can be used for signing. What prevents the AS to use one key from that
list for IDtokens and another for ATs? Separate discovery docs shouldn’t be
necessary. Sure, there would be no way for the RS to know what key is used
for what- but similar mechanisms are already in place today for handling
signing key rotation: e.g. the discovery doc lists the current key and the
future key, but uses only the current- and the RS has no way of
distinguishing between the two. The situation here can be analogous, any
key in the discovery doc should be considered valid by the RS, and in fact
there’s no requirement about selecting specific keys in the validation
section. That doesn’t mean this is useless, an AS might elect to use
different keys for its own purposes (eg separation of concerns for
forensics, different strengths, different lifecycles, and so on).






*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] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

I think one of the problems we have in being super specific about how 
the JWT access token is constructed is that is means it's not possible 
for many organizations to follow. How scopes are implemented is very 
varied across deployments which means that some may conform to the 
perspective of the spec and many may not.


Personally, I'm not a big fan of trying to use scopes for fine-grain 
authorization. I don't think that is what they were intended for when 
originally designed. (This can be seen by the RAR spec introducing a 
completely different way of specifying fine-grain authorization 
context.) Even in multi-tenant systems, I don't see issues with using 
sub-resource scopes as each tenant should define the scopes that make 
sense for that tenant. I don't think the AS needs to understand the 
scopes, just provide a mechanism to issue the correct scope under user 
consent to the client and let the RS apply the authorization policy when 
it gets the scopes out of the token.


I'll wait for your response to my other feedback :)

On 3/24/20 3:07 PM, Vittorio Bertocci wrote:

You are too fast  I am still replying to your other comments! 
Yes, it is possible for resource servers to define sub-resource specific 
scopes, but it cannot be mandated- and it can be extremely problematic when 
your AS is multitenant. The resource identifier in those scenarios can be a 
LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 
1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, 
provisioning and even bandwidth use standpoints. I have experienced this 
firsthand when Azure AD moved from v1 style resource identification (where 
resource was a mandatory request param) to v2, where the resource was inferred 
from the scopes via scopes stuffing.

From: OAuth  on behalf of George Fletcher 

Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci , Takahiko Kawasaki 

Cc: oauth 
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access 
Tokens"

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values (e.g. 
'read', 'write', 'delete'). It is very possible that in the context of a 
calendar services and an inbox service... the system defines scopes like 
'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity.
On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

   I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for

resource servers. In other words, if "aud" is determined based on the

"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS

is facading a collection of existing finer grained resources, scopes

representing permissions might be ambiguous - if my API facades both

calendar and inbox, what does the "read" scope refer to? Having an audience

resolves that ambiguity.




--
Identity Standards Architect
Verizon Media Work: george.fletc...@oath.com
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

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

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values 
(e.g. 'read', 'write', 'delete'). It is very possible that in the 
context of a calendar services and an inbox service... the system 
defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' in which there 
is no ambiguity.


On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

   I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for
resource servers. In other words, if "aud" is determined based on the
"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS
is facading a collection of existing finer grained resources, scopes
representing permissions might be ambiguous - if my API facades both
calendar and inbox, what does the "read" scope refer to? Having an audience
resolves that ambiguity.


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

Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[George Fletcher]

Feedback on the spec...

Section 1. Introduction
��� second line: scenario should be plural --> scenarios
��� second sentence: "are not ran by" --> "are not run by"

Section 2.2.1 Authentication Information Claims
��� I'm not sure that this definition of `auth_time` allows for the 
case where a user is required to solve an additional challenge. Take the 
case of a user who is required to pass a secondary challenge before the 
"stock purchase" action can be completed. According to the current spec 
definition, the `auth_time` value MUST NOT be updated when this 
secondary challenge is completed.


��� I think there is a difference between session_start_time and last 
auth_time. This feels more like it's defining the session_start_time 
concept.


�� These same issues can apply to the `acr` and `amr` values as well.

�� Even if for this secondary challenge a new refresh_token is issued, 
it is unlikely many relying parties will want to treat that as issuing a 
new session. The goal is to keep the user logged in to a single session.


Section 2.2.3 Authorization Claims
�� I find the statement "All the individual scope strings in the scope 
claim MUST have meaning for the resource indicated in the aud claim" 
somewhat problematic. In many deployments today for 1st party clients to 
the authorization server and taking into account mobile applications, 
the access token most like contains scopes for many of the 1st party 
backend APIs. It's possible to get around this by setting the 'aud' 
claim to something like "com.example.apis" and hence all the issued 
scopes map to that audience claim but that is just working around the 
MUST in the spec. Given the lack of specificity of the 'aud' claim and 
the 'resource indicator' claim for that matter, pretty much anything can 
be made to comply. In that context, it seems like RECOMMEND is a better 
normative clause.


Section 3. Requesting a JWT Access Token
�� Per my comments above I suspect that requiring all JWT access tokens 
to include an audience claim will just devolve to audience claims that 
are somewhat pointless (in order to meet this MUST in the spec). Given 
the mobile app environment today, it is unreasonable to ask the mobile 
apps to downscope every access token before making an API call to the 
backend APIs which is what the spirit of audience and resource 
indicators seem to imply.


�� Why MUST the AS reject a request with more than one resource 
parameter? If a request comes in with no resource parameter and multiple 
scopes the AS is not required to reject that request. Is there much of a 
semantic difference between the two? In the case of no resource 
parameter and multiple scopes the AS might issue an access token with 
multiple audience values (as is allowed by RFC 7519). Also, the audience 
claim is not solely for resource indicator values but is defined to just 
be a string. To me it feels like the text is implying that the only 
valid audience value is also a resource indicator (which from previous 
discussions on the list it was implied they have a slightly different 
semantic).


�� The model described here works well if myco.example really only 
provides a single service. But if instead myco.example provides multiple 
services each with their own endpoints (srva.myco.example, 
srvb.myco.example) and scopes, for me this model begins to break down. 
Either mobile apps are required to downscope all tokens to just the 
service they are calling at that point in time (which can have latency 
and connectivity issues), or myco.example has to create a generic 
"audience" string that represents all of example.com which doesn't seem 
to be the spirit of the existing specs.


�� In summary, I feel that this text is binding too tightly resource 
indicators to the audience claim. What is described is perfectly 
reasonable in a use case that is applying resource indicators in this 
way but is not indicative of the widely deployed models that already exist.


Section 4. Validating JWT Access Tokens
�� Step 4. -- Can we change the wording to not require resource 
indicators? What about... "The resource server MUST validate that the 
'aud' claim contains a string that represents the audience of this 
resource server."


Section 5. "cross-JWT confusion"
�� I think there may be confusion around what is meant by "distinct 
resources". In my example above, are srva.myco.example and 
srvb.myco.example "distinct resources"? or is the goal here to say that 
we want different audience values generated for cross-organization 
resources. For example, are mail.google.com and youtube.com "distinct 
resources"? or would an audience for google suffice in meeting the 
meaning of this paragraph?


� I'm having the same confusion in the next paragraph regarding the 
phrase "different resources". Are services provided by the same company 
"different resources" or are they all considered the same resource. Can 

Re: [OAUTH-WG] Call for Adoption: DPoP

[George Fletcher]

+1

On 3/23/20 1:57 PM, Vittorio Bertocci wrote:

+1

On Tue, Mar 17, 2020 at 8:16 AM Mike Jones  wrote:


I am for adoption of DPoP.



-- Mike



*From:* OAuth  *On Behalf Of * Rifaat Shekh-Yusef
*Sent:* Tuesday, March 17, 2020 5:21 AM
*To:* oauth 
*Subject:* [OAUTH-WG] Call for Adoption: DPoP



All,

As per the conclusion of the PoP interim meeting, this is a call for
adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the
Application Layer (DPoP)* document:
https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/

Please, let us know if you support or object to the adoption of this
document as a working group document by March 31st.

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] First Draft of OAuth 2.1

[George Fletcher]

I also am in favor of not requiring "sender constraint" as a MUST. 
SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps 
and as such DPOP doesn't work for those environments. Converting all web 
based environments to SPAs so not viable.


Thanks,
George

On 3/12/20 2:28 PM, Vittorio Bertocci wrote:

damnit, i hit enter too soon.
   Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the discussion
for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:

- on distributed scenarios, it introduces the need to serialize access
to shared caches
- network failures can lead to impact on experience- stranding clients
which fail to receive RTn+1 during RTn redemption in a limbo where user
interaction might become necessary, disrupting experience or functionality
for scenarios where the user isn't available to respond.
- remediations currently in the wild for this are either clunky (grace
periods) or downright cumbersome (waiting for the AT refreshed via RTn to
be used by the client to invalidate RTn, which locks RS and AS in a
transaction that is both expensive and itself subject to network failure)

I think it's fine to recommend using those mechanisms with a SHOULD, but
imposing those complexities to everyone in the core is asking too much IMO.
Thanks
V.

On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci 
wrote:


Hey guys,
thanks for putting this together.
I am concerned with the real world impact of imposing sender constraint |
rotation as a MUST on refresh tokens in every scenario.
Sender constraint isn't immediately actionable - we just had the
discussion for dPOP, hence I won't go in the details here.
Rotation isn't something that can be added without significant impact on
development and runtime experiences:

- on distributed scenarios, it introduces the need to serialize access
to shared caches
- network failures can lead to impact on experience- stranding clients
which fail to receive RTn+1 during RTn redemption in a limbo where user
interaction might become necessary, disrupting experience or functionality
for scenarios where the user isn't available to respond.
-



On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki  wrote:


I'm happy to share that Dick and Torsten and I have published a first
draft of OAuth 2.1. We've taken the feedback from the discussions on
the list and incorporated that into the draft.

https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01

A summary of the differences between this draft and OAuth 2.0 can be
found in section 12, and I've copied them here below.


This draft consolidates the functionality in OAuth 2.0 (RFC6749),
OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
(RFC7636), OAuth 2.0 for Browser-Based Apps
(I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
(RFC6750).

   Where a later draft updates or obsoletes functionality found in the
   original [RFC6749], that functionality in this draft is updated with
   the normative changes described in a later draft, or removed
   entirely.

   A non-normative list of changes from OAuth 2.0 is listed below:

   *  The authorization code grant is extended with the functionality
  from PKCE ([RFC7636]) such that the only method of using the
  authorization code grant according to this specification requires
  the addition of the PKCE mechanism

   *  Redirect URIs must be compared using exact string matching as per
  Section 4.1.3 of [I-D.ietf-oauth-security-topics]

   *  The Implicit grant ("response_type=token") is omitted from this
  specification as per Section 2.1.2 of
  [I-D.ietf-oauth-security-topics]

   *  The Resource Owner Password Credentials grant is omitted from this
  specification as per Section 2.4 of
  [I-D.ietf-oauth-security-topics]

   *  Bearer token usage omits the use of bearer tokens in the query
  string of URIs as per Section 4.3.2 of
  [I-D.ietf-oauth-security-topics]

   *  Refresh tokens must either be sender-constrained or one-time use
  as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]

https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12

I'm excited for the direction this is taking, and it has been a
pleasure working with Dick and Torsten on this so far. My hope is that
this first draft can serve as a good starting point for our future
discussions!


Aaron Parecki
aaronparecki.com
@aaronpk

P.S. This notice was also posted at
https://aaronparecki.com/2020/03/11/14/oauth-2-1

___
OAuth mailing list
OAuth@ietf.org

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[George Fletcher]

I'm a +1 for adding client_id back as well

On 3/12/20 11:31 AM, Brian Campbell wrote:

+1 (again) that `client_id` should be allowed/required as a query parameter
outside the request object JWT or URI and that its value has to be the same
as within the request object.

On Thu, Mar 12, 2020 at 8:20 AM Joseph Heenan  wrote:


I agree with that too.

Joseph

On 12 Mar 2020, at 14:18, Mike Jones <
Michael.Jones=40microsoft@dmarc.ietf.org> wrote:

I agree that we should restore the client_id functionality.  Thanks for
moving this forward!

-- Mike

*From:* OAuth  *On Behalf Of *Nat Sakimura
*Sent:* Monday, February 24, 2020 6:18 PM
*To:* John Bradley 
*Cc:* oauth 
*Subject:* Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization
Request (JAR) vs OIDC request object

So, where should we take it to?
Just add back client_id as it used to be?

On Fri, Jan 24, 2020 at 6:55 AM John Bradley  wrote:


-- Forwarded message -
From: *John Bradley* 
Date: Sat, Jan 18, 2020, 9:31 PM
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
(JAR) vs OIDC request object
To: Benjamin Kaduk 


If you put the iss in the JWE header it is integrity protected, as JWE
only supports AAD encryption algs.

It is more of a problem when the client is sending a requestURI in that
case having the clientID in the GET to the Authorization endpoint is useful.

I think there is a argument for explicitly allowing the clientID as long
as it exactly matches the clientID in the JAR.

John B.

On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk  wrote:

On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:

I don’t agree with this stance from a security or implementation

perspective.

If there’s a clear order of precedence for the information, it’s not

particularly problematic. Everything inside the request object is to be
taken over things outside the request object. We have the exact same
semantics and process with dynamic registration, where the software
statement is carried alongside plain JSON claims, and the two are mixed
with a very simple algorithm:

  - If a field is inside the signed payload, use that value and ignore

any copy of it on the outside

  - If a field is not inside the signed payload and is outside the signed

payload, use the outside value

Can someone please point out a concrete security issue with this

algorithm? This is the extent of the “merge” semantics that we need here,
and it would solve not only the ability to use this for use cases that call
for a more static request object (perhaps signed by a third party and not
the client) along side the plain parameters that can vary, but also the
backwards compatibility issue that’s been discussed. With this algorithm in
place, you could have OIDC clients actually be compliant with the spec,
since OIDC requires replication of the values inside the request object on
the outside with exact matches. An OIDC server wouldn’t be fully compliant
with the new spec since it would reject some compliant JAR requests that
are missing the external parameters, but that’s fairly easy logic to add on
the OIDC side. And in that case you get a matrix of compatibility like:

I agree that the merge algorithm is simple and fairly straightforward to
implement.  But, as Joseph has been alluding, it's only simple if you've
already made the decision to use all the parameters, both from inside and
from outside the signed payload.  The security risk lies about having to
make the trust decision twice, more than the mundane details of actually
doing the merge.  (Though there is still some latent risk, given that we've
seen some really crazy quality of implementation out there.)

It's certainly *possible* that things end up fine in many well-deliniated
cases where merging can be used.  But it's more complicated to reason
about, and I don't remmber seeing much previous discussion about the
specifics of the double trust decision.

-Ben


   JAR Server | OIDC Server  |
++--+
JAR Client  | YES|  NO  |
OIDC Client | YES| YES  |

Breaking one out of the four possible combinations in a very predictable

way is, I think, the best way to handle backwards compatibility here.

But between this issue and JAR’s problematic call for the value of a

request_uri to always be a JWT and be fetchable by the AS (neither of which
are true in the case of PAR) makes me think we need to pull this back and
rework those things, in a push back to the IESG’s comments.

  — Justin



On Jan 16, 2020, at 7:38 PM, Joseph Heenan 

wrote:

I agree with this, particularly the security concerns of merging. If

we merge, we can much guarantee there will eventually be a security issue
where an attacker is able to gain an advantage by adding a parameter to the
url query (which the server would then happily process if that parameter
isn’t found inside the 

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[George Fletcher]

In general, it's difficult to determine how to extend for new types or 
if they should be wrapped up in "data" somehow.


|{ "type":"https://example.com/my_field;, "actions":[ "read" ], 
"my_field": { "id": "" } }|


I'm assuming the above is perfectly legit and the intended way for the 
spec to be extended? If not, what is the expected extension mechanism?


Thanks,
George

On 10/2/19 11:45 AM, Brian Campbell wrote:
I guess we differ in our opinion of how remiss that would be. But 
given what you've got in there now, the more narrow point I was trying 
to make was to say that I don't think "data" is defined or explained 
well enough to be helpful.


On Tue, Oct 1, 2019 at 4:33 PM Justin Richer <mailto:jric...@mit.edu>> wrote:


I think that we need to define :some: common set to data elements
in this spec, in order to help people who are using this and
trying to apply it to their APIs do so in vaguely consistent ways.
The details of which parts we standardize on are still, I think,
up for grabs. I???d be happy to have a better name than ???data??? for
this aspect, but I think there???s value in defining this kind of
thing. Like in the financial space, it???s the difference between
???transactions??? and ???accounts???. Or in the medical space, there???s
???demographics??? and ???appointments??? and ???testResults???. This is a
very, very, very common way to slice up OAuth-protected resources,
and we???d be remiss to leave it undefined and just have every API
developer need to come up with their own version of the same thing.

??? Justin


On Oct 1, 2019, at 2:40 PM, Brian Campbell
mailto:bcampb...@pingidentity.com>>
wrote:

I'm not entirely sold on the draft attempting to define this set
of common data elements in the first place. But that said, I
think (similar to George?) I'm struggling with "data" more than
the others. The definition in the -02 draft is an "array of
strings representing the kinds of data being requested from the
resource" and I'm honestly having a hard time understanding what
that actually means or how it would be used in practice. And I'm
not sure roughly equating it to ???what kind of thing I want???
helped me understand any better.

On Tue, Sep 24, 2019 at 5:34 PM Justin Richer mailto:jus...@bspk.io>> wrote:

The idea behind the ???locations???, ???actions???, ???data???, and
???identifier??? data element types mirrors what I???ve seen
???scope??? used for in the wild. They roughly equate to ???where
something is???, ???what I want to do with it???, ???what kind of
thing I want???, and ???the exact thing I want???, respectively.
I???m completely open for better names, and have even been
thinking ???datatype??? might be better than just ???data??? for the
third one.

As for encoding, I think that form encoding makes sense
because it???s the simplest possible encoding that will work. I
personally don???t see a need to armor this part of the request
with base64, as it is in JOSE, and doing so would make it one
more step removed from easy developer understanding.

-- Justin Richer

    Bespoke Engineering
+1 (617) 564-3801
https://bspk.io/




On Sep 24, 2019, at 1:45 PM, George Fletcher
mailto:gffle...@aol.com>> wrote:

Just two questions...

1. What is the rationale that 'data' is really an array of
arbitrary top-level claims? I find looking at the spec and
not finding a 'data' section a little confusing.

2. What is the rationale for sending the JSON object as a
urlencoded JSON string rather than a base64url encoded JSON
string? The later would likely be smaller and easier to read:)

Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:

Hi all,??

I just published a draft about ???OAuth 2.0 Rich
Authorization Requests??? (formerly known as ???structured
scopes???).??

https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02

It specifies a new
parameter?authorization_details"??that is used to carry
fine grained authorization data in the OAuth authorization
request. This mechanisms was designed based on experiences
gathered in the field of open banking, e.g. PSD2, and is
intended to make the implementation of rich and transaction
oriented authorization requests much easier than with
current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me
as authors of this draft. We would would like to thank
Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[George Fletcher]

This is a great point about personal information. However, there are 
uses for authorization_details that don't specifically relate to 
personal information. Think an enhancement that has language preference, 
maybe a device identifier. Maybe we can add more text in the security 
considerations section stating that it's best practice to use PAR for 
any authorization_details that are considered personal information (PI) 
or personally identifying information (PII) ?


On 9/26/19 11:02 AM, Aaron Parecki wrote:

Hi Torsten,

Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.

I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer money between bank accounts, I don't think it's
appropriate for that kind of data to be sent in the front channel at
all. By encoding a rich authorization request with bank account
numbers and account names in a query string, that opens up several new
opportunities for an attacker to steal private/sensitive information
(browser extensions, proxy servers, etc).

This differs from the plain OAuth authorization request because
traditionally the request does not include any identifying information
about any user or even about the particular transaction. At most, the
request identifies the client and combination of coarse-grained scopes
the client is requesting, none of which can identify a user. However
with the examples provided in this document, as well as many
additional uses of this mechanism, it includes potentially a lot of
identifying information about users including their name, bank account
numbers, and even relationships to other parties (e.g. creditorName).
When the authorization request is sent to the AS in a URL, regardless
of whether it's in plaintext like the simple example here, or signed
as a JWT request, that data is visible to anything that can access the
URL between the user's device and the AS. This seems like a huge
potential for a privacy leak.

I realize this draft currently points to JWT Secured Authorization
Requests (JAR) in several places where these concerns come up. The
problem is that JAR doesn't actually *require* an encrypted JWT, so
the privacy implications aren't accounted for here.

I would much rather see this document require your other recent
submission, Pushed Authorization Requests. Given the privacy
implications, it makes sense to limit the use of rich authorization
requests to pushed authorization requests, so that this rich data is
never made available to intermediaries in the front channel.

If there is a good reason to continue allowing authorization requests
as a GET without the new pushed request step, then at least I would
want to see RAR require encrypted JWTs as described by JAR.

Thanks for considering this!


Aaron Parecki
aaronparecki.com



On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
 wrote:

Hi all,

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
(formerly known as ???structured scopes???).

https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02

It specifies a new parameter ???authorization_details" that is used to carry 
fine grained authorization data in the OAuth authorization request. This mechanisms 
was designed based on experiences gathered in the field of open banking, e.g. PSD2, 
and is intended to make the implementation of rich and transaction oriented 
authorization requests much easier than with current OAuth 2.0.

I???m happy that Justin Richer and Brian Campbell joined me as authors of this 
draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, 
Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the 
preparation of this draft.

We look forward to getting your feedback.

kind regards,
Torsten.

Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
Date: 21. September 2019 at 16:10:48 CEST
To: "Justin Richer" , "Torsten Lodderstedt" , 
"Brian Campbell" 


A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-rar
Revision: 02
Title: OAuth 2.0 Rich Authorization Requests
Document date: 2019-09-20
Group: Individual Submission
Pages: 16
URL:
https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt
Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized:   https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
Diff:   https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02

Abstract:
   This document specifies a new parameter "authorization_details" that
   is used to carry fine grained 

Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

[George Fletcher]

Just two questions...

1. What is the rationale that 'data' is really an array of arbitrary 
top-level claims? I find looking at the spec and not finding a 'data' 
section a little confusing.


2. What is the rationale for sending the JSON object as a urlencoded 
JSON string rather than a base64url encoded JSON string? The later would 
likely be smaller and easier to read:)


Thanks,
George

On 9/21/19 1:51 PM, Torsten Lodderstedt wrote:

Hi all,

I just published a draft about ???OAuth 2.0 Rich Authorization Requests??? 
(formerly known as ???structured scopes???).


https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02

It specifies a new parameter?authorization_details"??that is used to 
carry fine grained authorization data in the OAuth authorization 
request. This mechanisms was designed based on experiences gathered in 
the field of open banking, e.g. PSD2, and is intended to make the 
implementation of rich and transaction oriented authorization requests 
much easier than with current OAuth 2.0.


I???m happy that Justin Richer and Brian Campbell joined me as authors 
of this draft. We would would like to thank Daniel Fett, Sebastian 
Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their 
valuable feedback during the preparation of this draft.


We look forward to getting your feedback.

kind regards,
Torsten.


Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **New Version Notification for 
draft-lodderstedt-oauth-rar-02.txt*

*Date: *21. September 2019 at 16:10:48 CEST
*To: *"Justin Richer" >, "Torsten Lodderstedt" 
mailto:tors...@lodderstedt.net>>, "Brian 
Campbell" >



A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name:draft-lodderstedt-oauth-rar
Revision:02
Title:OAuth 2.0 Rich Authorization Requests
Document date:2019-09-20
Group:Individual Submission
Pages:16
URL: 
https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt

Status: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/
Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar

Diff: https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02

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




Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org 
.


The IETF Secretariat




___
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] WGLC on draft-ietf-oauth-reciprocal-04

[George Fletcher]

Reciprocal OAuth - draft 04 Feedback

2.1 Reciprocal Scope Request
-- The spec assumes the reader has an strong understanding of RFC 6749 
and just references sections. More prose should be added to get the 
reader a better understanding of what is happening and then reference 
the normative text in RFC 6749.
-- How does Party B know that it should return the "reciprocal" claim in 
the access token response? More non-normative text should be added to 
describe how the flow is even established (or maybe that how "reciprocal 
oauth" is in play is out of scope for the specification)


"party B MAY include an additional query
 component in the redirection URI to indicate the scope requested in
 the reciprocal grant:"
 -- This isn't an "additional query component" but rather an 
additional claim in the access token response.


"reciprocal OPTIONAL"
 -- I'd re-phrase the description for "reciprocal OPTIONAL" to be 
"The set of scopes Party B requires the resource owner to authorize for 
Party A to access Party B's resource"


" If an authorization code grant access token response per [RFC6749]
 4.2.2, an example successful response (with extra line breaks for
 display purposes only):"
 -- An example successful reciprocal oauth access token response for 
the authorization_code grant flow per [RFC6749] 4.2.2 (extra line breaks 
for display purposes only)
 -- 4.2.2 is the Implicit flow and yet the text references the 
authorization_code flow


" When party B is providing an authorization response per [RFC6749]
 4.1.2, party B MAY include an additional query component in the
 redirection URI to indicate the scope requested in the reciprocal
 grant."
 -- I would explicitly call out that this is for the "implicit" flow. 
Given that in many cases the implicit flow is NOT recommended as a best 
practice, I would recommend text to describe in what circumstances it is 
safe to use the implicit flow with reciprocal OAuth.
 -- RFC 6749 4.1.1 is the authorization_code flow so I'm confused as 
to what the additional "query" component is. In fact 4.1.2 is the 
callback URL with the code and state parameters. Is the spec suggesting 
that the reciprocal claim be added as a query parameter to that flow 
rather than the access token response?


2.2 Reciprocal Authorization flow
 -- This section only references the authorization code flow. Does 
that mean that reciprocal OAuth only works with the authorization code 
flow and not with implicit? The first part of the flow can use implicit 
but not the second since it is all back channel? Some text addressing 
this would be helpful.


2.2.2 Reciprocal Authorization code
 -- What is the expectation if the resource owner does not approve 
all the scopes requested by Party B? Does this follow the OAuth2 model 
that Party B obtains the list of scopes granted from the access token 
response after presenting the code provided by Party A?


"token endpoint authenticating"
 -- are all forms of client authentication allowed? or just those 
specified in RFC6749?


"access_token REQUIRED"
 -- formatting is incorrect

" Party B MUST respond with either an HTTP 200 (OK) response if the
 request is valid, or an HTTP 400 "Bad Request" if it is not."
 -- what form do the errors take? Should all applicable errors of RFC 
6749 section 5.2 be allowed?
 -- I'm assuming the error response should be JSON compliant with 
section 5.2


3 Authorization Update flow
-- How scopes are managed and communicated in both the update and 
section 2.2.2 is unclear and should be specified


No Security Considerations section
-- this definitely needs to be added


On 9/6/19 2:41 PM, Rifaat Shekh-Yusef wrote:

All,

We are starting a WGLC on the Reciprocal OAuth document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/

Please, review the document and provide feedback on any issues you see 
with the document.


The WGLC will end 20-September-2019.

Regards,
??Rifaat and 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] Refresh tokens

[George Fletcher]

For historical references only... the Google model around refresh tokens 
and the AOL model around refresh tokens were slightly different. So I 
proposed a bunch of the OIDC text around refresh tokens and offline 
access to allow for both models.


At AOL, the model was that refresh_tokens were bound to the 
authentication session by default. The only way to get an "unbound" 
refresh_token was to request the 'offline_access' scope. We restricted 
which clients could request the 'offline_access' scope and limited it 
mostly to native apps.


I'm happy to recommend errata text (as long as it's just explanatory) to 
the OIDC spec should someone have a recommendation they'd like to make:)


On 7/9/19 2:08 AM, David Waite wrote:



On Jul 8, 2019, at 8:39 PM, Aaron Parecki > wrote:


These are all very good points! I think the challenge here is 
figuring out where this kind of guidance is most appropriate.


It does seem like some of these issues are unique to a browser 
environment (particularly where the browser itself is managing the 
access and refresh tokens), so maybe it makes the most sense to 
include this guidance in the browser based app BCP?


Yes, the location is a challenge - the ???offline??? distinction is 
defined (arguably under-defined) by OpenID Connect. OAuth (on the 
other hand) does not take a stand on user authentication sessions, 
since the tokens are for delegated access.


For confidential clients, both online and offline options make sense. 
For native apps, the push is usually for long-term access or for a 
session separate from the external user agent. But for browser apps, 
you typically want to mirror user authentication.


If there are situations in which this advice is applicable in other 
scenarios in addition to browser apps, then I think it would make 
more sense to include it in the general OAuth security BCP.


The Security BCP already has some language around refresh tokens, but 
I haven't reviewed it in a while to see if all of these points might 
be already covered there.


If folks think the Browser BCP is the best place for this kind of 
thing I am definitely open to it, and I can work with David on the 
specific language to add.


- Aaron


-DW

___
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] Refresh tokens

[George Fletcher]

I'll just add a couple more thoughts around refresh_tokens.

1. I agree with David that refresh_tokens are valuable in an "online" 
scenario and should be used there.


2. To use a refresh token at the /token endpoint, client authentication 
is required. This is where it gets difficult for default SPAs because 
they are public clients and the only mechanism to authenticate them is 
the client_id which is itself public. For me, this is the real risk of 
exposing the refresh_token in the browser.


3. If the AS supports rotation of refresh_tokens and an attacker steals 
one and uses it, then the SPA will get an error on it's next attempt 
because it's refresh_token will now be invalid. If the refresh_tokens 
are bound to the user's authentication session, then the user can logout 
to lockout the attacker. However, that is a lot of "ifs" and still 
provides the attacker with time to leverage access via the compromised 
refresh_token.


In principle, I agree with the recommendation that SPAs shouldn't have 
refresh_tokens in the browser. If it's not possible to easily refresh 
the access token via a hidden iframe (becoming more difficult with all 
the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to 
use a simple server component such that the backend for the SPA can use 
authorization_code flow and protect a client_secret.


Thanks,
George

On 7/8/19 11:17 PM, David Waite wrote:


On Jul 8, 2019, at 7:10 PM, Leo Tohill > wrote:

Re 8. Refresh Tokens

 "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "

(first, note the typo "stoken".)

Is it always "higher risk"??? I could even argue that leakage of a 
refresh token is lower risk. As a bearer document, a leaked access 
token allows access to resources until it expires.?? A leaked refresh 
token, to be useful,?? requires an exchange with the AS, and the AS 
would have the opportunity to check whether the refresh token is 
still valid (has not been revoked). (of course revocation might NOT 
have happened, but then again, it might have.)


I agree (with caveats, of course).

Access tokens and refresh tokens may or may not be attached (by 
policy) to an authentication session lifetime. It is far easier to 
picture refresh tokens which are not attached to an authentication 
session (sometimes called ???offline??? access) being inappropriate for a 
browser-based app, which is nearly always a client that the resource 
owner is interacting with.


Variants that may want offline tokens are less easy to imagine - 
perhaps browser extensions?


I believe the language currently there is due to AS implementations 
predominantly treating refresh tokens as being for offline access, and 
access token lifetime being short enough to not outlast an 
authentication session.


Furthermore, since the access token is transmitted to other servers, 
the risk of exposure is greater, due to possible vulnerabilities in 
those called systems (e.g., logs).?? Isn't this the reason that we 
have refresh tokens? Don't refresh tokens exist because access tokens 
should have short TTL, because they are widely distributed?


Yes. Once you acknowledge the existence of ???online??? refresh tokens, 
they become a strong security component:


- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to 
invalidate access without needing to resort to token 
introspection/revocation
- Token refresh can theoretically be used to represent other policy 
changes by both the client (creating tokens targeting a new resource 
server or with reduced scopes) and server (changing entitlements and 
attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security 
BCP. A exfiltrated refresh token will result in either the attacker or 
the user losing access on the next refresh, and a double refresh is a 
detectable security event by the AS.


"Additionally, browser-based applications provide many attack vectors 
by which a refresh token can be leaked."


The risks of leaking a refresh token from the browser are identical 
to the risks of leaking an access token, right??? This sentence could 
be changed to "... by which /a token/ can be leaked."


A refresh token is "higher risk" because its TTL is usually greater 
than the access token's TTL.?? But if our advice here leads to people 
using longer-lived access tokens (because of the problems with 
getting a new access token without involving the user), then the 
advice will be counter productive. The longer life gives more time 
for the usefulness of a browser-side theft, and more time for the 
usefulness of a server-side theft.


Which scenario is safer?
A) using an 

Re: [OAUTH-WG] Client assertions to endpoints other than the token endpoint

[George Fletcher]

So if by "other endpoints" we mean "other endpoints at the AS" then I 
think issuer makes a lot of sense and could be recommended value.


However, if the client assertion is being sent to an endpoint not 
managed by the AS, then it should use a value that identifies that 
"audience". In this case, something more akin to the "resource 
identifier" of the endpoint is probably best. Abeit, that is still a 
very fuzzy definition :)


On 5/28/19 11:28 AM, Dave Tonge wrote:

Dear OAuth WG

We have an issue that we are discussing in the OIDF MODRNA work group 
relating to the Client Initiated Back Authentication spec (which is an 
OAuth 2 extension). As the issue affects the wider OAuth ecosystem we 
wanted to post it here and gain feedback from the OAuth Working Group.


Full details of the issue are here: 
https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including 
a helpful context setting by Brian), but the summary is:


*What audience value should a Client use when using a client assertion 
(RFC7521) to authenticate at an endpoint other than the token endpoint?*

*
*
The three options we have are:
1. the token endpoint (as RFC7521 says)
2. the endpoint the assertion is being sent to (e.g. revocation, 
backchannel)

3. the issuer

We are leaning towards requiring the Authorization Server to accept 
any of the above values, but recommending that the Client use the 
issuer value.


The reasons for this are:
1. All of the above values are arguably valid, so in the interest of 
interoperability the AS should accept them all.
2. We see no clear security benefit to requiring the audience to be 
the value of the endpoint the assertion is being sent to, and 
therefore think that the issuer value is the one we should recommend 
that clients use.


We would be grateful for your feedback on this issue and believe it 
would be in the best interest of the ecosystem for there to be a 
consistent approach to this across OAuth 2 extensions and profiles.


Thanks

Dave Tonge


___
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] Transaction Authorization with OAuth

[George Fletcher]

One thing to keep in mind with the "Push Request Object" model and the 
concept of a more detailed scope structure, if the specified values are 
not for a single transaction, then the AS will be required to keep the 
"Pushed Request Object" for the "lifetime" of the access_token and 
possibly the refresh_token depending on the use case. This could have 
some implementation issues for the AS.


Thanks,
George

On 5/10/19 9:52 AM, Dave Tonge wrote:

Thanks Torsten for this article - it is incredibly helpful.

I'm very much in favour of the "structured_scope" approach.

While I understand George's point I think the line is very blurred 
between coarse-grained scopes and fine-grained transaction consent. In 
addition fine-grained authorisation metadata is needed for ongoing 
access APIs as well, e.g. how can a client ask for ongoing access to:

 - transactions in a users accounts with ids abc123 and abc124

From a UX perspective it is beneficial for the AS to ask the user for 
consent once. The AS therefore needs to have all the information about 
relating to the consent available when the user is redirected to the 
authorization endpoint. There should be a standard way for the Client 
to pass this data to the AS and I think structured scopes either sent 
as a query param or in a request object are a neat way of doing this.


Dave



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

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

Maybe this is a dumb question, but why would an AS allow a client to 
register it's own client_id rather than issuing the client a client_id 
within the namespace of the AS?


Also, a client_id or sub should NEVER be treated as unique without the 
context of the issuer. In that regard, the AS (as Torsten pointed out) 
MUST ensure uniqueness within it's "issuer" context.


On 5/8/19 4:22 AM, Vladimir Dzhuvinov wrote:


This is an excellent security point.

I also imagine that in "federated" cases an RS could have its own 
subject scheme / namespace, distinct from the one at the AS, including 
for clients acting on their own behalf.


Vladimir

On 07/05/2019 11:37, Neil Madden wrote:

I wasn’t at IIW so I may be missing some context.

There is a potential security issue if the client_id is used as the “sub” for 
an AT obtained via client_credentials. If the client can register itself with a 
self-chosen client_id then it may deliberately chose a client_id that matches 
the user name of a privileged user. An RS that just blindly looks at the “sub” 
claim may then erroneously let the client perform privileged actions.

Is this the context of the discussion?

Given that there are a lot of RSes in existence, many of which are probably 
just looking at the “sub” claim to identify the resource owner, I think the 
onus is on the AS to ensure that no such ambiguity can arise in the first place 
by ensuring that the space of “sub” values for client credentials is disjoint 
with the space for genuine users or by disallowing the client_credentials grant 
altogether.

This issue already arises in token introspection though, so maybe ought to be 
mentioned in the OAuth security topics draft rather than specific to the JWT AT 
draft?

— Neil


On 6 May 2019, at 18:32, Vittorio Bertocci 
 wrote:

Hi all,
thanks for your patience during this month long hiatus, and thanks for the 
comments.
Last week at IIW I had the opportunity to discuss this with many of the people 
on the list. Here's a summary of where the discussion landaed on the subject of 
the sub (pun intended).

- It seems that RFC 7519 has pretty clear language on the use of sub- I didn't 
check it back when we started the discussion. I do agree with the people saying 
that we shouldn't violate existing specifications, hence it looks like we do 
need to have sub also in the case in which we have app-only tokens carrying 
claims about the app itself. I understand this will cause some implementation 
to break, but unfortunately that's intrinsic in the process of coming up with a 
common approach and standards compliance is probably one of the strongest 
reasons to tolerate that.
- That said, I am strongly committed to preserve existing functionality. One of 
the main reasons that was brought up for including sub only for user based ATs 
was to use it as heuristic for telling those tokens apart from app-only ones. 
To that end, Karl MCGuinness suggested that we include grant_type as a return 
claim, which the RS could use to the same effect. I find the proposal very 
clever, and the people at IIW thought so as well. What you think?
Note, John Bradley observed that in some cases this might lead to ambiguous 
results if an extension grant is used (say an assertion profile) but that seems 
like a relatively fringe occurrence.

On Thu, Apr 4, 2019 at 1:11 PM Hans Zandbelt mailto:hans.zandb...@zmartzone.eu>> wrote:
I also meant to say that (of course) the JWT standard doesn't say that the JWT 
is supposed to be about the client or about the resource owner, hence both are 
valid

Hans.

On Thu, Apr 4, 2019 at 10:09 PM Mike Jones mailto:michael.jo...@microsoft.com>> wrote:
I get that existing practice is likely to be all over the map, but if we’re to 
create a JWT access token standard, it’s reasonable to require that the claims 
usage comply with the JWT standards.

  


 -- Mike

  

From: Hans Zandbelt mailto:hans.zandb...@zmartzone.eu>> 
Sent: Thursday, April 4, 2019 12:59 PM

To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: George Fletcher mailto:40aol@dmarc...ietf.org>>; Vittorio 
Bertocci mailto:40auth0@dmarc.ietf.org>>; IETF oauth WG 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

  


the definition of RFC 7519 is actually "petitio principii" and a lot of 
deployments put claims about the Resource Owner in the access token (as a Resource Server 
implementer I've suffered a lot from this)

  


Hans.

  


On Thu, Apr 4, 2019 at 9:48 PM Mike Jones mailto:michael.jo...@microsoft.com>> wrote:

I agree with George that the subject of a token must be the principal of that token.  
That what the JWT “sub” claim is for.  Indeed, the first sentence of the “sub” 
definition athttps://tools.ietf.org/html/rfc7519#section-4.1.2  
<https://tools.ietf.org/htm

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

George::

Again, I would want the transaction requirements to be part of the
API not part of the scope. In my mind, the authorization token
should convey the client is authorized to perform a set of actions
(capabilities) and then the API parameters define the exact
details of that particular transaction.


Torsten:: I understand your sentiments. How would you envision to ask 
a user for consent about those details if this consent is required by law?


So it seems we are looking for two key aspects as it relates to the 
transaction(s) and consent...


1. Require explicit user consent regarding the details of the transaction
2. Specify the details of the transaction

It seems the mapping of this to the term "scope" is because at the 
authorization endpoint it's the "scopes" the user has to consent to. 
However, we don't have to try and map this transactional functionality 
into the existing more capability model of OAuth2.


Assuming that something like a "consent receipt" will be issued to the 
user once they have consented... what about using a term more consistent 
with consent? "transaction_consent" ? I'd even be fine with 
"transaction_details" and then have the spec require that the user 
consent to all information in the "transaction_details" object. Though I 
suspect there are use cases where there are more details in the 
transaction than for which the user needs to give consent. So that might 
not be the best name.


At this point I'm probably splitting hairs:) Naming things is hard:)

On 4/30/19 6:39 AM, Torsten Lodderstedt wrote:



Am 26.04.2019 um 16:17 schrieb George Fletcher <mailto:gffle...@aol.com>>:





On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:



Am 25.04.2019 um 17:03 schrieb George Fletcher <mailto:gffle...@aol.com>>:



A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction 
requirements.


What???s the difference? In my opinion, if you authorize a 
transaction it???s the same. Moreover, in other use cases (account 
information) it a complex requirement for a potentially long lasting 
grant.


In both cases, they describe the request power of the token == 
it???s scope.
I guess I look at scope as "authorized to transfer" maybe something 
like "authorized to transfer up to 10K". However the details of which 
account to take the money from and the account of where to put the 
money are not aspects of the scope but rather restrictions on the 
transaction.


It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent 
from the user to perform that transaction... but I don't think the 
details of the transaction should be considered scope(s).


For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".




2. The schemas are going to be very ecosystem specific, correct?


API (e.g. all psd2 standards), ecosystem, single deployment - just 
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the 
API not part of the scope. In my mind, the authorization token should 
convey the client is authorized to perform a set of actions 
(capabilities) and then the API parameters define the exact details 
of that particular transaction.


I understand your sentiments. How would you envision to ask a user for 
consent about those details if this consent is required by law?






On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "re

Re: [OAUTH-WG] MTLS vs. DPOP

[George Fletcher]

I don't see them the same at all. With MTLS, the token is bound to the 
transport layer (and the key used to establish that encrypted 
connection). With DPOP, the token is bound to the private key known to 
the client.


To compromise an MTLS bound token the attacker has to compromise the 
private key. To compromise a DPOP bound token, depending on what HTTP 
request elements are signed, and whether the DPOP is managed as 
one-time-use etc, there are additional attacks. (Ducks head and waits 
for all the real security experts to prove me wrong:)


The deployment models are also different. With MTLS bound tokens the 
clients don't really have to know about the binding because it is 
established at the AS and the deployment of the service manages the cert 
used for the MTLS connection. This is simpler for client development 
(provided the environment is already set up for MTLS everywhere).


I'd strong encourage us to continue supporting both methods.

On 5/7/19 4:25 AM, Hannes Tschofenig wrote:


Hi all,

In the OAuth conference call today Vittorio mentioned that some folks 
are wondering whether DPOP is essentially a superset of MTLS and 
whether it makes sense to only proceed with one solution rather 
potentially two.


I was wondering whether others in the group have a few about this aspect?

Ciao

Hannes

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

Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

[George Fletcher]

I agree that we definitely need better definition and guidance around 
scopes and authorized access patterns.


I think what is unique about what Torsten is proposing is that in his 
case he wants to authorize an individual transaction (not a set of 
transactions). Normally, with scopes and access tokens the goal is to 
get an access token that can perform a number of transactions with a 
restricted set of capabilities.


I think we need to separate the concept of transactional authorization 
from capability authorization.


On 4/26/19 10:06 AM, Pedro Igor Silva wrote:

Hi Jaap,

Very good points. I have the same opinion about what you said about 
the meaning of scopes (and how people are actually using them), the 
resource-scope relationship and the importance of a standardized way 
of doing this form of authorization to address different use cases, 
not only delegation. Like George said in one of his messages, both 1st 
and 3rd party use cases could be considered by a solution like that.


I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the 
client does not yet have a bearer token or the bearer token is lacking 
the required scopes/permissions. The resource server responds with:


/HTTP/1.1 403 Unauthorized /
/WWW-Authenticate: Bearer realm="example", error="invalid_token", 
*claim_token*="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"/


The claim_token response parameter returned by the resource server 
represents all the security constraints (e.g.: scopes) and information 
(e.g.: contextual) that the client needs in order to obtain a valid 
access token from the AS. This token can be built by the RS or even 
use some endpoint at the AS, as UMA does. It can be just a reference 
token too.


#2) Client obtains an access token from the token endpoint at the AS:

/POST /as/token.oauth2 HTTP/1.1/
/Host: as.example.com /
/Content-Type: application/x-www-form-urlencoded/
/grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission/
/=https%3A%2F%2Fbackend.example.com 
%2Fapi%20/

/&*claim_token*=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC/
/_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token/

The example above shows a client request to the token endpoint when 
the client already has an access token and wants a new token with 
permissions to access a resource.


#3) Just like any other OAuth grant type, the token endpoint responds 
to the client as follows (success):


/HTTP/1.1 200 OK/
/Content-Type: application/json;charset=UTF-8/
/Cache-Control: no-store/
/Pragma: no-cache/
/
/
/{/
/"access_token":"2YotnFZFEjr1zCsicMWpAA"/
/"token_type":"example",/
/"expires_in":3600,/
/"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"/
/} /
/
/
#4) Clients can now access protected resources using the access token 
with all permissions granted by the server


It is not coincidence the similarities with and the usage of 
specs/drafts like token exchange, resource-indicator, UMA, Lodging 
Intent Pattern,??or even ACE's "AS Request Creation Hints" message. The 
point I would like to make is that we could leverage the 
standards/specs that exist today to address the problem without 
reinventing the wheel.


There are very interesting things in UMA specs that can be used here 
too, such as the possibility to perform incremental authorization or 
token upgrade, etc.


Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke 
> wrote:


Hi Torsten and others,

I just read your blog - having ???we need to re-think OAuth scopes???
in the title immediately drew my attention.
I find this interesting since I???m struggling with the concept of
scopes from time-to-time.
I???ll have to read the blog a few times more to get a good
understanding, but I would like to share some of my thoughts on
scopes.

I believe the OAuth scope concept has it???s limitations not only
for transactions but also for the more traditional ???resource??? concept.
RFC 6749 defines scopes as follows:
"The value of the scope parameter is expressed as a list of space-
 delimited, case-sensitive strings.?? The strings are defined by the
 authorization server.?? If the value contains multiple
space-delimited
 strings, their order does not matter, and each string adds an
 additional access range to the requested scope.???

I see 2 aspects in this definition:
- how the strings should look like is beyond the scope of the RFC
- each string adds an additional authorisation

Scopes are associated with access_tokens, which typically are
bearer tokens as defined by RFC 6750 as:
?? A security token with the property that any party in
possession of
?? the token (a "bearer") can use the token in any way that any
 

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

Look at this in more detail... what about calling it 
"transactional_scope" instead of "structured_scope" as the scope is 
specific to an individual transaction and not applicable across 
transactions. That would then separate it from the more capability based 
'scope' provided by OAuth2.


In this context I like the pushed-request-object method as the resource 
server is going to need to pull the same transactional requirements when 
it receives the access token.


Thanks,
George

On 4/26/19 10:17 AM, George Fletcher wrote:



On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:



Am 25.04.2019 um 17:03 schrieb George Fletcher <mailto:gffle...@aol.com>>:



A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction 
requirements.


What???s the difference? In my opinion, if you authorize a 
transaction it???s the same. Moreover, in other use cases (account 
information) it a complex requirement for a potentially long lasting 
grant.


In both cases, they describe the request power of the token == it???s 
scope.
I guess I look at scope as "authorized to transfer" maybe something 
like "authorized to transfer up to 10K". However the details of which 
account to take the money from and the account of where to put the 
money are not aspects of the scope but rather restrictions on the 
transaction.


It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent 
from the user to perform that transaction... but I don't think the 
details of the transaction should be considered scope(s).


For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".




2. The schemas are going to be very ecosystem specific, correct?


API (e.g. all psd2 standards), ecosystem, single deployment - just 
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should 
convey the client is authorized to perform a set of actions 
(capabilities) and then the API parameters define the exact details of 
that particular transaction.




On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "remittanceInformationUnstructured":"new Smartphone"
   }

This means ???sign" and ???payment" would determine the scheme of the 
respective object.

What do you think?

best regards,
Torsten.


On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:

Thank you for the article, Torsten!

my pleasure :-)


I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:

Hi all,

I just published an article about the subject 
at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

On 4/25/19 1:54 PM, Torsten Lodderstedt wrote:



Am 25.04.2019 um 17:03 schrieb George Fletcher <mailto:gffle...@aol.com>>:



A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction 
requirements.


What???s the difference? In my opinion, if you authorize a transaction 
it???s the same. Moreover, in other use cases (account information) it a 
complex requirement for a potentially long lasting grant.


In both cases, they describe the request power of the token == it???s scope.
I guess I look at scope as "authorized to transfer" maybe something like 
"authorized to transfer up to 10K". However the details of which account 
to take the money from and the account of where to put the money are not 
aspects of the scope but rather restrictions on the transaction.


It may be fine to have a model where the client tells the AS what 
transaction it wants to perform for the purpose of getting consent from 
the user to perform that transaction... but I don't think the details of 
the transaction should be considered scope(s).


For me.. scope is a capability the client is authorized to perform... 
"send an Instant message", or "read a buddy list".




2. The schemas are going to be very ecosystem specific, correct?


API (e.g. all psd2 standards), ecosystem, single deployment - just 
like ???traditional??? scope values
Again, I would want the transaction requirements to be part of the API 
not part of the scope. In my mind, the authorization token should convey 
the client is authorized to perform a set of actions (capabilities) and 
then the API parameters define the exact details of that particular 
transaction.




On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "remittanceInformationUnstructured":"new Smartphone"
   }

This means ???sign" and ???payment" would determine the scheme of the 
respective object.

What do you think?

best regards,
Torsten.


On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch:

Thank you for the article, Torsten!

my pleasure :-)


I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:

Hi all,

I just published an article about the subject 
at:https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.
___
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] Transaction Authorization with OAuth

[George Fletcher]

A couple of thoughts...

1. It doesn't feel like these are scopes (at least not as scope is 
defined by RFC 6749). It feels like they are more transaction requirements.


2. The schemas are going to be very ecosystem specific, correct?

On 4/24/19 1:08 PM, Torsten Lodderstedt wrote:

Hi Sascha,

I see. I assume every element within the structured scope element to be an 
independent scope (value) object and intended to use the name of that object as 
kind of content type definition.

In my last example, the scope is defined as

"structured_scope":{
   "sign":{
  "credentialID":"qes_eidas",
  "documentDigests":[
 {
"hash":
  "sTOgwOm+474gFj0q0x1iSNspKqbcse4IeiqlDg/HWuI=",
"label":"Mobile Subscription Contract"
 }
  ],
  "hashAlgorithmOID":"2.16.840.1.101.3.4.2.1"
   },
   "payment":{
  "type":"sepa-credit-transfer",
  "instructedAmount":{
 "currency":"EUR",
 "amount":"123.50"
  },
  "debtorAccount":{
 "iban":"DE40100100103307118608"
  },
  "creditorName":"Merchant123",
  "creditorAccount":{
 "iban":"DE02100100109307118603"
  },
  "remittanceInformationUnstructured":"new Smartphone"
   }

This means ???sign" and ???payment" would determine the scheme of the 
respective object.

What do you think?

best regards,
Torsten.


On 23. Apr 2019, at 17:14, Sascha Preibisch  wrote:

Hi Torsten!

If 'structured_scope' would become a generic field for application
specific content, I believe an indicator for the type of content would
be needed on the long run. That is what I meant my 'profile'. I hope
this helps!

Thank you,
Sascha

Am Mo., 22. Apr. 2019 um 22:06 Uhr schrieb Torsten Lodderstedt
:

Hi Sascha,


Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :

Thank you for the article, Torsten!

my pleasure :-)


I like that 'scope' is out of the game for these kinds of authorizations.

What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.

What does profile mean in this context?

best regards,
Torsten.

Thank you,
Sascha

Am Sa., 20. Apr. 2019 um 11:21 Uhr schrieb Torsten Lodderstedt
:

Hi all,

I just published an article about the subject at: 
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948

I look forward to getting your feedback.

kind regards,
Torsten.
___
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] Transaction Authorization with OAuth

[George Fletcher]

I can see use cases where both approaches are useful. I was just 
pointing out that while the RS might not be told the context of the 
request from the client's perspective, the client still knows it's own 
context and can leverage that with UMA at the RS to reduce the need to 
request multiple tokens (which is the issue I understood Torsten to be 
making).


I would also say that in UMA there is some desire to reduce the work the 
RS has to do as well where in Torsten's use case, the RS may be managing 
all the responsibility (for good or ill:)


On 4/22/19 3:36 PM, Pedro Igor Silva wrote:
I think this knowledge by clients of the ecosystem is something that a 
transactional authorization could avoid. Both UMA and ACE have 
solutions that make clients really dumb about what they need to send 
to the AS in regards to scopes. IMO, the RS should have the 
possibility to tell clients the scope they need, making a lot easier 
to change RS's access constraints as well as pushing contextual 
information that could eventually enrich the authorization process.


On Mon, Apr 22, 2019 at 4:04 PM George Fletcher <mailto:gffle...@aol.com>> wrote:


Speaking just to the UMA side of things...

...it's possible in UMA 2 for the client to request additional
scopes when interacting with the token endpoint specifically to
address cases where the client knows it's going to make the
following requests and wants to obtain a token with sufficient
privilege for those requests. This requires a fair amount of
knowledge by the client of the ecosystem but that is sometimes the
case and hence this capability exists :)

On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

The problem from my perspective (and my understanding of UMA) is the RS 
does not have any information about the context of the request. For example, 
the client might be calling a certain resource (list of accounts) and 
immediately afterwards wants to obtain the balances and initiate a payment. I 
think the UMA case the RS either predicts this based on policy or past 
behaviour of the client OR the client will need to issue several token 
requests. That might not be a problem in 1st party scenarios but it is in 3rd 
party scenarios if the AS gathers consent.




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

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

Yes, from 3.3.1 of the UMA OAuth2 grant...

scope
   OPTIONAL. A string of space-separated values representing requested
   scopes. For the authorization server to consider any requested scope
   in its assessment, the client MUST have pre-registered the same
   scope with the authorization server. The client should consult the
   resource server's API documentation for details about which scopes
   it can expect the resource server's initial returned permission
   ticket to represent as part of the authorization assessment (see
   Section 3.3.4
   
<https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#authorization-assessment>).

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html#seek-authorization

On 4/23/19 1:04 AM, Torsten Lodderstedt wrote:

Does UMA use the standard scope parameter?

Am 22.04.2019 um 21:03 schrieb George Fletcher <mailto:gffle...@aol.com>>:



Speaking just to the UMA side of things...

...it's possible in UMA 2 for the client to request additional scopes 
when interacting with the token endpoint specifically to address 
cases where the client knows it's going to make the following 
requests and wants to obtain a token with sufficient privilege for 
those requests. This requires a fair amount of knowledge by the 
client of the ecosystem but that is sometimes the case and hence this 
capability exists :)


On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

The problem from my perspective (and my understanding of UMA) is the RS does 
not have any information about the context of the request. For example, the 
client might be calling a certain resource (list of accounts) and immediately 
afterwards wants to obtain the balances and initiate a payment. I think the UMA 
case the RS either predicts this based on policy or past behaviour of the 
client OR the client will need to issue several token requests. That might not 
be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS 
gathers consent.




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

Re: [OAUTH-WG] Transaction Authorization with OAuth

[George Fletcher]

Speaking just to the UMA side of things...

it's possible in UMA 2 for the client to request additional scopes 
when interacting with the token endpoint specifically to address cases 
where the client knows it's going to make the following requests and 
wants to obtain a token with sufficient privilege for those requests. 
This requires a fair amount of knowledge by the client of the ecosystem 
but that is sometimes the case and hence this capability exists :)


On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:

The problem from my perspective (and my understanding of UMA) is the RS does 
not have any information about the context of the request. For example, the 
client might be calling a certain resource (list of accounts) and immediately 
afterwards wants to obtain the balances and initiate a payment. I think the UMA 
case the RS either predicts this based on policy or past behaviour of the 
client OR the client will need to issue several token requests. That might not 
be a problem in 1st party scenarios but it is in 3rd party scenarios if the AS 
gathers consent.


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

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[George Fletcher]

+1 for me as well :)

On 4/8/19 1:38 PM, Hans Zandbelt wrote:

+1

Hans.

On Mon, Apr 8, 2019, 19:34 John Bradley > wrote:


I agree this should be adopted as a working group document.


On 4/8/2019 7:07 PM, Hannes Tschofenig wrote:
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access
Tokens'?? document following the positive feedback at the last IETF
meeting in Prague.
>
> Here is the document:
> https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Rifaat
>
> 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 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] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

I get your 1st party use case and if you think about a company that 
might have multiple endpoints on different domains that provide API 
services all invoked by a mobile app... requiring the mobile app to 
effectively downscope (or resource indicator bind) tokens means a lot of 
chatter between the mobile app to the AS to obtain appropriate tokens. 
And all this over a connection that does have latency issues.


That said, having a single token that is authorized to access all those 
services has it's own risks.


I'm not sure about a structure like...
   https://user.example.com
  scope: profile
   https://mail.example.com
  scope: mail-write
   https://cal.example.com
  scope: calendar-write

User Managed Access (UMA) [1] explicitly defines this structure but it's 
not embedded in the UMA access token.


[1] 
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html#permission-endpoint


I suppose a need to support multiple audiences within a given access 
token kind of necessitates the need to bind the scopes with the 
audience/resource.


On 4/4/19 1:34 PM, Vittorio Bertocci wrote:


I think for most implementations this would amount to... define an
audience that covers all the resource services where the access
token can be returned and set that as the audience (e.g.
urn:x-mydomain:apis). Which is perfectly legal but maybe not in
the spirit of the spec:) I am receiving feedback from developers
that binding access tokens narrowly to the resource where they
will be presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS infrastructure.

This is an interesting point. In my experience, the main boundary used 
to define a resource is either reflecting an underlying, *actual* 
resource that exists independently of the API facade slapped on top of 
it (say a VM) or it is the context within a certains et of scopes 
makes sense (say an API facading access to a bunch of documents).
Some of that criterion is reflected in the rationale for sigle value 
audiences. Do you think it should be made more explicit? Perhaps in a 
dedicated section?

[rest of thread snipped]

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

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

The more I think about this the more I land in the "No" camp.

The subject of a token should be the principal of that token. It 
shouldn't matter whether that is a machine, a user, or a device. Trying 
to separate out "humans" as a special class will just make things more 
complicated. If we need a claim to identify the subject is a "human" 
then why not just add that. This doesn't break anything and makes it 
easy for people to detect this case in those use cases where it's required.


Thanks,
George

On 4/3/19 4:56 PM, Hans Zandbelt wrote:
I will argue that in a way such deployments are already broken e.g. in 
the typical use case of onboarding client accounts in the same 
directory/OU/namespace as user accounts and we don't need to cater for 
that.


Hans.

On Wed, Apr 3, 2019 at 10:48 PM George Fletcher <mailto:gffle...@aol.com>> wrote:


I agree that this will break a lot of existing flows... especially
those using any form of the client_credentials flow. In that sense
I'm not completely on board yet :)

On 3/26/19 12:56 PM, Hans Zandbelt wrote:

great summary! this will hurt quite a few existing m2m
deployments but I do like the rigidness of it all: it is very
explicit, cannot misinterpreted and thus prevents failure (which
is really what Dominick is after); I'm on board

Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci
mailto:40auth0@dmarc.ietf.org>> wrote:

thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob,
David, Nov, Bertrand recommend using sub only for users.
Martin would like to have the sub for app only flows as well.
Hans is neutral.
That does sound like the sub as user has more consensus, tho
before changing it I'd wait for the people currently at
IETF104 to have more time to comment as well.
Clarification. If the goal is to be able to apply the logic
"if there's a sub, it's a user flow", we have to explicitly
disallow (MUST NOT) the use of sub when that's not the case.
Are all OK with it?

Dave, the suggestion of having explicit typing for app only
vs user only is interesting! For the purpose of putting
together an interoperable profile, tho, I would suggest we
table it for v1 in the interest of getting to something easy
to adopt (hence with small delta vs existing implementations)
faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem
mailto:stei...@udelt.no>> wrote:

Hi Vittorio, we  (the national federation-gateway for the
health services in norway - "HelseID")  think his is a
really valuable initiative!
We also agree with Dominick concerning definition of the
"sub" claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
mailto:dba...@leastprivilege.com>>:

From an access token consumer (aka API) developer
point of view, I prefer this logic

"If sub is present - client acts on behalf of a user,
if not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake
(mat...@gmail.com <mailto:mat...@gmail.com>) wrote:


Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select
username as sub, or incremental integer as sub &
client_id will be easily collide.

If you can enforce collision resistant IDs between
user & client instances, it’ll works fine. I feel
its overkill though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci
mailto:vitto...@auth0.com>> wrote:


Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was
expecting to cause more discussion, and I am glad
we are having this opportunity to clarify.
The current language in the draft traces the
etymology of sub to OpenID Connect core, hence
Dominick observation is on point. However in the
description I express something in line with 7519,
which was in fact my intent.

The idea was to provide an identifier of the
calling subject that is guaranteed to be present in
all cases- this would allow an SDK developer to use
the same code for things like lookups and
membership checks

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

:)

The more I think about 'sub' the more I don't think is should mean 
"user". What about an IoT device? To me it feels like 'sub' should be 
what 7519 states, the subject or principal of the token. In some cases, 
that is quite legitimately the "client" or "machine". Changing that 
semantic seems bad. If a developer needs to know whether this JWT is 
about a "human" or not, that's something else entirely and could have 
it's own claim.


On 4/4/19 11:38 AM, Hans Zandbelt wrote:

agreed but it (i.e. "sub") also brings us back to where we started

Hans.

On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell 
<mailto:40pingidentity@dmarc.ietf.org>> wrote:


The same is true for most of the other main claims too - iss, exp,
aud, sub, iat, etc.. They are defined in RFC 7519 not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell
mailto:bcampb...@pingidentity.com>>
wrote:

Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the
definition of `aud` which should be the reference and this
document can provide additional specifics for the given
    application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletcher
mailto:40aol@dmarc.ietf.org>> wrote:

Another comment...

aud  REQUIRED - as defined in section 2 of [OpenID.Core  
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
  See
   Section 3  
<https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
  for indications on how an authorization server should
   determine the value of aud depending on the request.  [Note: 
some
   vendors seem to rely on resource aliases.  If we believe 
this to
   be a valuable feature, here's some proposed language: The aud
   claim MAY include a list of individual resource indicators 
if they
   are all aliases referring to the same requested resource 
known by
   the authorization server. ]



I don't think OpenID.Core Section 3 is the correct
reference for determining the 'aud' value. The issue here
is that the 'aud' of the id_token is the recipient of the
id_token (i.e. the client). However, for access_tokens the
'aud' value should be the resource service that will
receive the access_token. There is no existing guidance
for this and we should provide such guidance as this is
"kind of new" for OAuth2 (from an explicit specification
perspective).

Also, there is the concept of 'azp' from the id_token
which amounts to "who's allowed to present this token"
which might be interesting from the case where one entity
obtains the token, and gives it to another entity to
present. Not sure if we want to include this concept or not.

Finally, I think we may need some best practice around how
the concept of audience and resource should be managed.
For instance...

If the request does not include a resource parameter, the
authorization server MUST use in the aud claim a default 
resource
indicator.  If a scope parameter is present in the request, the
authorization server SHOULD use it to infer the value of the 
default
resource indicator to be used in the aud claim.

I think for most implementations this would amount to...
define an audience that covers all the resource services
where the access token can be returned and set that as the
audience (e.g. urn:x-mydomain:apis). Which is perfectly
legal but maybe not in the spirit of the spec:) I am
receiving feedback from developers that binding access
tokens narrowly to the resource where they will be
presented is concerning from a chattiness perspective
(latency issues) and general load on the deployed AS
infrastructure.

On 3/24/19 7:29 PM, Vittorio Bertocci wrote:

Dear all,
I just submitted a draft describing a JWT profile for
OAuth 2.0 access tokens. You can find it in

https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll
be presenting remotely). I look forward for your comments!

Here's just a bit of backstory, in case you are
interested in how this doc came to be. The trajectory it
followed is somewhat unusual.

  * Despite OAuth2 not requiring any specific fo

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

Another comment...

   aud  REQUIRED - as defined in section 2 of [OpenID.Core  
].
  See
  Section 3  

  for indications on how an authorization server should
  determine the value of aud depending on the request.  [Note: some
  vendors seem to rely on resource aliases.  If we believe this to
  be a valuable feature, here's some proposed language: The aud
  claim MAY include a list of individual resource indicators if they
  are all aliases referring to the same requested resource known by
  the authorization server. ]



I don't think OpenID.Core Section 3 is the correct reference for 
determining the 'aud' value. The issue here is that the 'aud' of the 
id_token is the recipient of the id_token (i.e. the client). However, 
for access_tokens the 'aud' value should be the resource service that 
will receive the access_token. There is no existing guidance for this 
and we should provide such guidance as this is "kind of new" for OAuth2 
(from an explicit specification perspective).


Also, there is the concept of 'azp' from the id_token which amounts to 
"who's allowed to present this token" which might be interesting from 
the case where one entity obtains the token, and gives it to another 
entity to present. Not sure if we want to include this concept or not.


Finally, I think we may need some best practice around how the concept 
of audience and resource should be managed. For instance...


   If the request does not include a resource parameter, the
   authorization server MUST use in the aud claim a default resource
   indicator.  If a scope parameter is present in the request, the
   authorization server SHOULD use it to infer the value of the default
   resource indicator to be used in the aud claim.

I think for most implementations this would amount to... define an 
audience that covers all the resource services where the access token 
can be returned and set that as the audience (e.g. urn:x-mydomain:apis). 
Which is perfectly legal but maybe not in the spirit of the spec:) I am 
receiving feedback from developers that binding access tokens narrowly 
to the resource where they will be presented is concerning from a 
chattiness perspective (latency issues) and general load on the deployed 
AS infrastructure.


On 3/24/19 7:29 PM, Vittorio Bertocci wrote:

Dear all,
I just submitted a draft describing a JWT profile for OAuth 2.0 access 
tokens. You can find it in 
https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting 
remotely). I look forward for your comments!


Here's just a bit of backstory, in case you are interested in how this 
doc came to be. The trajectory it followed is somewhat unusual.


  * Despite OAuth2 not requiring any specific format for ATs, through
the years I have come across multiple proprietary solution using
JWT for their access token. The intent and scenarios addressed by
those solutions are mostly the same across vendors, but the syntax
and interpretations in the implementations are different enough to
prevent developers from reusing code and skills when moving from
product to product.
  * I asked several individuals from key products and services to
share with me concrete examples of their JWT access tokens (THANK
YOU Dominick Baier (IdentityServer), Brian Campbell
(PingIdentity), Daniel Dobalian (Microsoft), Karl Guinness (Okta)
for the tokens and explanations!).
I studied and compared all those instances, identifying
commonalities and differences.
  * I put together a presentation summarizing my findings and
suggesting a rough interoperable profile (slides:

https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx


) - got early feedback from Filip Skokan on it. Thx Filip!
  * The presentation was followed up by 1.5 hours of unconference
discussion, which was incredibly valuable to get tight-loop
feedback and incorporate new ideas. John Bradley, Brian Campbell
Vladimir Dzhuvinov, Torsten Lodderstedt, Nat Sakimura, Hannes
Tschofenig were all there and contributed generously to the
discussion. Thank you!!!
Note: if you were at OSW2019, participated in the discussion and
didn't get credited in the draft, my apologies: please send me a
note and I'll make things right at the next update.
  * On my flight back I did my best to incorporate all the ideas and
feedback in a draft, which will be discussed at IETF104 tomorrow.
Rifaat, Hannes and above all Brian were all super helpful in
negotiating the mysterious syntax of the RFC format and submission

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[George Fletcher]

I agree that this will break a lot of existing flows... especially those 
using any form of the client_credentials flow. In that sense I'm not 
completely on board yet :)


On 3/26/19 12:56 PM, Hans Zandbelt wrote:
great summary! this will hurt quite a few existing m2m deployments but 
I do like the rigidness of it all: it is very explicit, cannot 
misinterpreted and thus prevents failure (which is really what 
Dominick is after); I'm on board


Hans.

On Tue, Mar 26, 2019 at 5:49 PM Vittorio Bertocci 
> wrote:


thank you Steinar and everyone else for the comments on this!
To summarize the situation so far: Dominick, Steinar, Rob, David,
Nov, Bertrand recommend using sub only for users. Martin would
like to have the sub for app only flows as well. Hans is neutral.
That does sound like the sub as user has more consensus, tho
before changing it I'd wait for the people currently at IETF104 to
have more time to comment as well.
Clarification. If the goal is to be able to apply the logic "if
there's a sub, it's a user flow", we have to explicitly disallow
(MUST NOT) the use of sub when that's not the case. Are all OK
with it?

Dave, the suggestion of having explicit typing for app only vs
user only is interesting! For the purpose of putting together an
interoperable profile, tho, I would suggest we table it for v1 in
the interest of getting to something easy to adopt (hence with
small delta vs existing implementations) faster.

On Tue, Mar 26, 2019 at 1:40 AM Steinar Noem mailto:stei...@udelt.no>> wrote:

Hi Vittorio, we (the national federation-gateway for the
health services in norway - "HelseID")  think his is a really
valuable initiative!
We also agree with Dominick concerning definition of the "sub"
claim.

Steinar

tir. 26. mar. 2019 kl. 07:25 skrev Dominick Baier
mailto:dba...@leastprivilege.com>>:

From an access token consumer (aka API) developer point of
view, I prefer this logic

"If sub is present - client acts on behalf of a user, if
not - not."

Anything more complicated has a potential of going wrong.


On 26. March 2019 at 01:34:53, Nov Matake
(mat...@gmail.com ) wrote:


Hi Vittorio,

Yeah, I’m concerning user & client ids collision.
I haven’t seen such implementations, but user-select
username as sub, or incremental integer as sub &
client_id will be easily collide.

If you can enforce collision resistant IDs between user &
client instances, it’ll works fine. I feel its overkill
though.

Sent from my iPhone

On Mar 26, 2019, at 8:51, Vittorio Bertocci
mailto:vitto...@auth0.com>> wrote:


Hey Nov, Dominick, Hans-
thanks for the comments. That was an area I was
expecting to cause more discussion, and I am glad we are
having this opportunity to clarify.
The current language in the draft traces the etymology
of sub to OpenID Connect core, hence Dominick
observation is on point. However in the description I
express something in line with 7519, which was in fact
my intent.

The idea was to provide an identifier of the calling
subject that is guaranteed to be present in all cases-
this would allow an SDK developer to use the same code
for things like lookups and membership checks regardless
of the nature of the caller (user in a delegated case,
app in app-only grants). The information to discriminate
between user and app callers is always available in the
token (say, the caller is a user if sub!=client_id,
where client_id is always guaranteed to be present as
well) hence there's no loss in expressive power, should
that difference be relevant for the resource server.

Dominick, Hans- I probably missed the security issue you
guys are thinking of in this case. Of course, if this
would introduce a risk I completely agree it should be
changed- I'd just like to understand better the problem.
Could you expand it in a scenario/use case to clarify
the risk?
Nov- playing this back: is the concern that a user and a
client might have the same identifier within an IDP?
When using collision resistant IDs, as it is usually the
case, that seems to be a remote possibility- did you
stumble in such scenario in production?

Thanks
V.


On Mon, Mar 25, 2019 at 7:44 AM Hans Zandbelt

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[George Fletcher]

Perfect! Thank you! A couple comments on version 01...

   POST /token HTTP/1.1
   Host: server.example.com
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

   grant_type=authorization_code
   =SplxlOBeZQQYbYS6WxSbIA
   _uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
   (remainder of JWK omitted for brevity)


I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...


Also, there is no discussion of the DPoP-Binding header outside of the 
token request, but I suspect that is the desired way to communicate the 
DPoP-Proof to the RS.


Possibly an example in the session for presenting the token to the RS 
would help.


Thanks,
George

On 4/3/19 11:39 AM, Daniel Fett wrote:

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

Am 03.04.19 um 17:28 schrieb George Fletcher:

A quick question regarding...

o  "http_uri": The HTTP URI used for the request, without query and
   fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, Daniel Fett wrote:


Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00


Abstract

This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, 
and others during today's session or before!


If you find any errors I would welcome if you open an issue in the 
GitHub repository at https://github.com/webhamster/draft-dpop


- Daniel


___
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] feedback on draft-ietf-oauth-browser-based-apps-00

[George Fletcher]

From a security perspective, I think that using a UUID (or session 
cookie) which allows the SPA to retrieve the access_token is effectively 
the same as the confidential client directly returning the AT to the 
browser. Basically, it's the different between whether the browser has a 
copy of the access_token or not.


As to recommendations the AS might want to take, probably depends on a 
lot of factors. The factor that the browser has access to the 
access_token is just one of many affecting the overall risk to the 
Resource Server and the overall ecosystem. The risk of the browser 
having the access token is that there are more vectors for the token to 
be compromised and if the token is a bearer token then the risk is 
higher that the access token could be replayed by a malicious actor.


So, it's possible the AS might want to limit the ability of actions 
associated with those access tokens based on the risk of the actions 
enabled within the ecosystem by the RS.


I'm not sure there are definite recommendations that can be provided.

On 4/3/19 8:12 AM, Pedro Igor Silva wrote:

Hi,

I've seem some implementations where the token is not directly 
delivered to the browser by the backend, but some temporary UUID that 
later the SPA can exchange for an access token.


Do you think this is a good approach to the recommendation you are 
discussing?


In addition to that, could you clarify more what would be the 
limitations that ASes may wish to impose to these clients?


Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher 
mailto:40aol@dmarc.ietf.org>> 
wrote:


I think it's fair to call it out (either in the paragraph here or
in the security considerations). The issue is that the security
aspect of the access token ending up in the browser is probably
true in many contexts other than SPAs:)

What about something like...

In this scenario, the backend component is likely a confidential
client which is issued it's own client secret. Note that in this
model, the access_token obtained by the backend component will be
delivered to the browser for use by the SPA so is more exposed
than in the classic confidential client model. Some Authorization
Servers may wish to limit the capabilities of these clients due to
risk considerations.

... or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:

Thanks, this is a good question. I was talking with someone about
this draft the other day and had the same question myself.
Re-reading RFC6749, "public client" does describe only the
limitation of the client protecting its own credentials, so I
think you're right that this paragraph is misleading. However I
suspect that some ASs will still want to treat clients where the
access token ends up in the browser differently. Is that a fair
assessment? I think the fix to this paragraph would be a slight
rewording to just remove the mention of public clients.

Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher mailto:gffle...@aol.com>> wrote:

Hi,

In section 6.2 the following statement is made...

In this scenario, the backend component may be a confidential client
which is issued its own client secret.  Despite this, there are 
still
some ways in which this application is effectively a public client,
as the end result is the application's code is still running in the
browser and visible to the user.


I'm curious as to how this model is different from many
existing resource server deployments acting as confidential
clients. While the application code is running in the
browser, only the access token is exposed to the browser as
is the case for many RS deployments where the RS returns the
access token to the browser after the authorization flow
completes. My interpretation of "confidential client" does
not include whether the client's code is "visible" to
externals or not, but rather whether the client can protect
the secret.

In that sense I don't believe this deployment model is
"effectively a public client". A hybrid model description is
fine, and I don't disagree that some authorization servers
may want to treat these clients in a different way.

Thanks,
George

-- 


Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>



___
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] draft-fett-oauth-dpop-00

[George Fletcher]

A quick question regarding...

   o  "http_uri": The HTTP URI used for the request, without query and
  fragment parts (REQUIRED).


Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)


On 3/28/19 6:17 AM, Daniel Fett wrote:


Hi all,

I published the first version of the DPoP draft at 
https://tools.ietf.org/html/draft-fett-oauth-dpop-00


Abstract

This document defines a sender-constraint mechanism for OAuth 2.0
access tokens and refresh tokens utilizing an application-level
proof-of-possession mechanism based on public/private key pairs.

Thanks for the feedback I received so far from John, Mike, Torsten, 
and others during today's session or before!


If you find any errors I would welcome if you open an issue in the 
GitHub repository at https://github.com/webhamster/draft-dpop


- Daniel


___
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] feedback on draft-ietf-oauth-browser-based-apps-00

[George Fletcher]

I think it's fair to call it out (either in the paragraph here or in the 
security considerations). The issue is that the security aspect of the 
access token ending up in the browser is probably true in many contexts 
other than SPAs:)


What about something like...

In this scenario, the backend component is likely a confidential client 
which is issued it's own client secret. Note that in this model, the 
access_token obtained by the backend component will be delivered to the 
browser for use by the SPA so is more exposed than in the classic 
confidential client model. Some Authorization Servers may wish to limit 
the capabilities of these clients due to risk considerations.


 or something like that.

On 4/2/19 11:57 AM, Aaron Parecki wrote:
Thanks, this is a good question. I was talking with someone about this 
draft the other day and had the same question myself. Re-reading 
RFC6749, "public client" does describe only the limitation of the 
client protecting its own credentials, so I think you're right that 
this paragraph is misleading. However I suspect that some ASs will 
still want to treat clients where the access token ends up in the 
browser differently. Is that a fair assessment? I think the fix to 
this paragraph would be a slight rewording to just remove the mention 
of public clients.


Aaron


On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <mailto:gffle...@aol.com>> wrote:


Hi,

In section 6.2 the following statement is made...

In this scenario, the backend component may be a confidential client
which is issued its own client secret.  Despite this, there are still
some ways in which this application is effectively a public client,
as the end result is the application's code is still running in the
browser and visible to the user.


I'm curious as to how this model is different from many existing
resource server deployments acting as confidential clients. While
the application code is running in the browser, only the access
token is exposed to the browser as is the case for many RS
deployments where the RS returns the access token to the browser
after the authorization flow completes. My interpretation of
"confidential client" does not include whether the client's code
is "visible" to externals or not, but rather whether the client
can protect the secret.

In that sense I don't believe this deployment model is
"effectively a public client". A hybrid model description is fine,
and I don't disagree that some authorization servers may want to
treat these clients in a different way.

Thanks,
George

--

Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>



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

[OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[George Fletcher]

Hi,

In section 6.2 the following statement is made...

   In this scenario, the backend component may be a confidential client
   which is issued its own client secret.  Despite this, there are still
   some ways in which this application is effectively a public client,
   as the end result is the application's code is still running in the
   browser and visible to the user.


I'm curious as to how this model is different from many existing 
resource server deployments acting as confidential clients. While the 
application code is running in the browser, only the access token is 
exposed to the browser as is the case for many RS deployments where the 
RS returns the access token to the browser after the authorization flow 
completes. My interpretation of "confidential client" does not include 
whether the client's code is "visible" to externals or not, but rather 
whether the client can protect the secret.


In that sense I don't believe this deployment model is "effectively a 
public client". A hybrid model description is fine, and I don't disagree 
that some authorization servers may want to treat these clients in a 
different way.


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

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[George Fletcher]

The one use case I've run across for introspecting refresh_tokens is to 
determine the lifetime of the refresh_token (i.e. when it expires). Some 
authorization servers bind the refresh_token to the user's 
authentication session and hence they have a defined lifetime. I suppose 
another use case might be to determine all the scopes that were issued 
to the refresh_token. That of course should require the correct 
authorization at the introspection endpoint in order to obtain the scope 
data:)


On 3/14/19 2:50 PM, Brian Campbell wrote:
Certificate-binding refresh tokens issued to *public clients* (those 
that don't have authentication credentials established with the AS, 
a.k.a. clients configured or registered with the "none" authentication 
method, which will typically be native apps on a phone or similar) 
adds protections against malicious use or reuse of those refresh 
tokens where no protections would otherwise exist. It's true that 
certificate rotation in that situation would invalidate the refresh 
token. But not being able to rotate a strong asymmetric credential 
without invaliding the refresh token seems a very reasonable trade off 
vs. not having a credential bound to the token at all.


I guess I would say that what is returned when introspecting such a 
refresh token is an implementation detail that is at the discretion of 
said implementation. That seems consistent with the level of guidance 
in introspection for refresh tokens currently. And there's not really 
an interoperability angle that I can see. So that seems fine. Also, 
some form of authorization is required to access the introspection 
endpoint so I'm not sure how a refresh token issued to a public client 
would realistically get introspected. I guess, if I'm being honest, I 
don't really get refresh token introspection in general so probably 
better that I stop opining on the subject.







On Thu, Mar 14, 2019 at 7:13 AM Neil Madden > wrote:


It’s not clear to me how this works or what problem it is solving.
If a refresh token is bound to the certificate, does that mean
that a call to the introspection endpoint with that refresh token
should also return a “cnf” claim as per
https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2
 ?

It also seems problematic to implement this for refresh tokens. As
mentioned by Filip, rotation of the certificate is out of the
question. Currently in our implementation a client could present a
new certificate when using the refresh token and this would result
in the newly issued access token being bound to the new
certificate. If the refresh token is bound to the original
certificate, then this would be ruled out (the new certificate
would be rejected) and certificate rotation becomes impossible in
all cases. Am I missing something?

— Neil

> On 14 Mar 2019, at 12:28, Brian Campbell
mailto:bcampb...@pingidentity.com>>
wrote:
>
> Yeah, so regular old RFC 6749 OAuth requires that a refresh
token be bound to the client to whom it was issued. And that
confidential clients (those having established authn credentials)
authenticate to the AS when presenting a refresh token. Thus, for
both MTLS methods of OAuth client authentication, refresh tokens
are indirectly certificate-bound through their binding to a client
and its credentials (and the client rotating its cert doesn't
invalidate the refresh token).
>
> What was added in the -13 revision of the draft (in a new
section
https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4)
was a brief description of certificate binding refresh tokens for
public clients.
>
> The ask from Vittorio was a mention of refresh tokens in
abstract. Which seems reasonable. But the proper wording to
succinctly and accurately convey the aforementioned subtleties is
proving difficult for me.
>
>
>
>
>
> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden
mailto:neil..mad...@forgerock.com>> wrote:
> Right - this is what we have implemented. No support for
certificate-bound refresh tokens, the client can be configured to
require TLS cert client authentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan mailto:panva...@gmail.com>> wrote:
>
>> Point being that since the refresh token is only usable on the
IdP then mtls client auth already covers this, and since RTs are
long-lasting, it does this better because cert rotation is
possible for both mtls methods.
>>
>> S pozdravem,
>> Filip Skokan
>>
>>
>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan mailto:panva@gmail.com>> wrote:
>> Even before refresh tokens were mentioned in draft 13 i was
about to implement this binding in nodejs 

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[George Fletcher]

+1

to using the same client authn method as for the /token endpoint

On 3/11/19 12:31 PM, Brian Campbell wrote:



On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan > wrote:


Strike that, it should maybe just use the registered auth method
for the token endpoint?


Yeah, that's what I'd think would be the way to go.


If there's auth we should also make it clear that client_id should
not be omitted from the request body and it must be the same as
the one provided with client authentication.


Fair point.


S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:14, Filip Skokan mailto:panva...@gmail.com>> wrote:

If we're about to add client authentication for the
device_authorization_endpoint, i'd say we should also register
for device_authorization_endpoint_auth_method,
device_authorization_endpoint_auth_signing_alg client
metadata. Maybe define the default value to be "none" / not
provided to be in line with the late draft implementations. Wdyt?

S pozdravem,
*Filip Skokan*


On Mon, 11 Mar 2019 at 17:08, Brian Campbell
mailto:40pingidentity@dmarc.ietf.org>> wrote:

I do realize it's very late in the process for this
document but believe these omissions can be addressed in
the document with only minor changes/additions and that
it'd be better late than not at all..

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell
mailto:bcampb...@pingidentity.com>> wrote:

Another omission[1] (maybe, I believe it is anyway) to
the Device Flow is that client authentication isn't
defined for the device authorization request to device
authorization endpoint.

I suspect that it's largely an oversight because
public clients are really the conical use-case for the
device flow and no authentication is needed or
possible in that case. There are, however, likely to
be cases where a client with credentials will do the
device flow and it would be good for the AS to be able
to properly authenticate such clients before setting
up and saving the state for the transaction. Having
normal client authentication at device authorization
endpoint also brings better consistency to client
identification/authentication for requests made
directly from client to AS.


[1] error responses from the device authorization
endpoint should probably also be defined

https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4



/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


/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


--
Identity Standards Architect
Verizon Media Work: george.fletc...@oath.com
Mobile: +1-703-462-3494   Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544   Photos: http://georgefletcher.photography

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

Re: [OAUTH-WG] Correct error code for rate limiting?

[George Fletcher]

Excellent point! The specs (OAuth2 and OIDC) are completely silent on 
what should happen if an HTTP transport error occurs. Maybe that whole 
space should have it's own blog post:)


Regardless of the OAuth2/OIDC error code, clients already have to deal 
with HTTP codes like 503 "Service Unavailable", or 504 "Gateway timed 
out" which will not have any of the OAuth2 level error response data.


Given a rate-limiting condition is a transport condition and not a 
protocol condition, I'd be fine with not returning any protocol error 
data and require the client to handle the transport conditions correctly.


Thanks,
George


On 2/22/19 10:34 AM, Evert Pot wrote:

On 2019-02-22 10:29 a.m., George Fletcher wrote:
I believe Torsten proposed an "authentication_failed" error response 
in a different context. Possibly we could use that?


Alternatively, OpenID Connect defines a 'login_required' error that 
could work in this context as well. It doesn't fit the semantic as 
defined in the OIDC spec, but as an error would work.


If we need to use an existing OAuth2 error code, then I'd recommend 
'invalid_request' in that the request is invalid because there are 
too many of them which is indicated by the 429 HTTP error code.


What benefit would a specific request body serve?

Should a client behave differently if they got a 429 from an 
intermediate oauth2-unaware proxy vs an oauth2 server that emits this 
body?





On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the 
OAuth error code string? "invalid_grant" seems closest but doesn't 
sound right because if the app tries the same request again later it 
would be valid.




On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <mailto:gffle...@aol.com>> wrote:


+1 for using 429


On 2/22/19 2:09 AM, David Waite wrote:

I don’t believe that any of the currently registered error
codes are appropriate for indicating that the password request
is invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used
for known transient errors, but rather for malformed requests -
the request could very well be correct (and have the correct
password), but it is being rejected due to temporal limits
placed on the client or network address/domain.

So I would propose a different statuses such 401 to indicate
the username/password were invalid, and either 429 (Too many
requests) or 403 (Forbidden) when rate limited or denied due to
too many attempts. Thats not to say that the body of the
response can’t be an OAuth-format JSON error, possibly with a
standardized code - but again I don’t think the currently
registered codes would be appropriate for conveying that.

That said, I don’t know what interest there would be in
standardizing such codes, considering the existing
recommendations against using this grant type.

-DW


On Feb 21, 2019, at 10:57 PM, Aaron Parecki mailto:aa...@parecki.com>> wrote:

The OAuth password grant section mentions taking appropriate
measures to rate limit password requests at the token
endpoint. However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't
mention an error code to use if the request is being rate
limited.. What's the recommended practice here? Thanks!

Aaron

-- 


Aaron Parecki
aaronparecki.com <http://aaronparecki.com/>
@aaronpk <http://twitter.com/aaronpk>

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



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


--

Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>




___
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] Correct error code for rate limiting?

[George Fletcher]

I believe Torsten proposed an "authentication_failed" error response in 
a different context. Possibly we could use that?


Alternatively, OpenID Connect defines a 'login_required' error that 
could work in this context as well. It doesn't fit the semantic as 
defined in the OIDC spec, but as an error would work.


If we need to use an existing OAuth2 error code, then I'd recommend 
'invalid_request' in that the request is invalid because there are too 
many of them which is indicated by the 429 HTTP error code.


On 2/22/19 9:53 AM, Aaron Parecki wrote:
HTTP 429 sounds fine for the HTTP response code, but what about the 
OAuth error code string? "invalid_grant" seems closest but doesn't 
sound right because if the app tries the same request again later it 
would be valid.




On Fri, Feb 22, 2019 at 6:02 AM George Fletcher <mailto:gffle...@aol.com>> wrote:


+1 for using 429


On 2/22/19 2:09 AM, David Waite wrote:

I don’t believe that any of the currently registered error codes
are appropriate for indicating that the password request is
invalid, let alone a more specific behavior like rate limiting.

It is also my opinion that 400 Bad Request shouldn’t be used for
known transient errors, but rather for malformed requests - the
request could very well be correct (and have the correct
password), but it is being rejected due to temporal limits placed
on the client or network address/domain.

So I would propose a different statuses such 401 to indicate the
username/password were invalid, and either 429 (Too many
requests) or 403 (Forbidden) when rate limited or denied due to
too many attempts. Thats not to say that the body of the response
can’t be an OAuth-format JSON error, possibly with a standardized
code - but again I don’t think the currently registered codes
would be appropriate for conveying that.

That said, I don’t know what interest there would be in
standardizing such codes, considering the existing
recommendations against using this grant type.

-DW


On Feb 21, 2019, at 10:57 PM, Aaron Parecki mailto:aa...@parecki.com>> wrote:

The OAuth password grant section mentions taking appropriate
measures to rate limit password requests at the token endpoint.
However the error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention
an error code to use if the request is being rate limited..
What's the recommended practice here? Thanks!

Aaron

-- 


Aaron Parecki
aaronparecki.com <http://aaronparecki.com/>
@aaronpk <http://twitter.com/aaronpk>

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



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


--

Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>



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

Re: [OAUTH-WG] Correct error code for rate limiting?

[George Fletcher]

+1 for using 429

On 2/22/19 2:09 AM, David Waite wrote:
I don’t believe that any of the currently registered error codes are 
appropriate for indicating that the password request is invalid, let 
alone a more specific behavior like rate limiting.


It is also my opinion that 400 Bad Request shouldn’t be used for known 
transient errors, but rather for malformed requests - the request 
could very well be correct (and have the correct password), but it is 
being rejected due to temporal limits placed on the client or network 
address/domain.


So I would propose a different statuses such 401 to indicate the 
username/password were invalid, and either 429 (Too many requests) or 
403 (Forbidden) when rate limited or denied due to too many attempts. 
Thats not to say that the body of the response can’t be an 
OAuth-format JSON error, possibly with a standardized code - but again 
I don’t think the currently registered codes would be appropriate for 
conveying that.


That said, I don’t know what interest there would be in standardizing 
such codes, considering the existing recommendations against using 
this grant type.


-DW

On Feb 21, 2019, at 10:57 PM, Aaron Parecki > wrote:


The OAuth password grant section mentions taking appropriate measures 
to rate limit password requests at the token endpoint. However the 
error responses section (
https://tools.ietf.org/html/rfc6749#section-5.2) doesn't mention an 
error code to use if the request is being rate limited.. What's the 
recommended practice here? Thanks!


Aaron

--

Aaron Parecki
aaronparecki.com 
@aaronpk 

___
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] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[George Fletcher]

Then I think we have a bigger issue:(

To me the point of the "resource-indicators" spec is to define semantics 
around how a client can request that tokens be "constrained" in where 
they can be used. If it is not going to define the actual 'resource' 
parameter and rather use the registered value from the token-exchange 
spec, then it seems like the resource-indicators spec has the wrong 
title. Instead it should be about "constraining where a token can be 
used" and in that view should describe how to use either the 'audience' 
or 'resource' parameter. I believe we need clear guidance for when to 
use one over the other (if possible).


It is then left up to the AS to determine whether it is going to support 
just 'audience', just 'resource' or both when constraining tokens.


We should also provide some "best practice" guidance on how resource 
servers can ensure these tokens are for them. In a wide eco-system 
deployment where a resource server is supporting multiple authorization 
servers, this could get complicated for the resource server. The 
resource-indicators spec implies that the AS should use the resource 
parameter to set the 'audience' of the returned access_token. There is 
no guidance for what a AS should return from the /introspection endpoint 
in regards to the "constrained" token. Do both 'resource' and 'audience' 
values get returned in the "aud" claim?


Thanks,
George

On 2/7/19 11:26 AM, Hannes Tschofenig wrote:


Hi George,

The IANA registry does not indicate in what context these parameters 
are supposed to be used. To me it feels totally normal to use the 
audience parameter instead of the resource parameter when I have a 
logical name.


Stuffing everything into a URI is possible but in certain scenarios 
may feel quite unnatural. It must have felt unnatural already to the 
group when working on the token exchange spec…


Ciao

Hannes

*From:*George Fletcher 
*Sent:* Donnerstag, 7. Februar 2019 17:06
*To:* Hannes Tschofenig ; Ludwig Seitz 
; a...@ietf.org; oauth@ietf.org
*Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01


This is true... however, to my knowledge there is no support for this 
parameter outside of the token-exchange spec. Just because it is 
documented as an OAuth parameter I don't consider it usable in other 
contexts unless spec'd to do so. If we want to use 'audience' for 
logical audience names when binding audiences to tokens, then we need 
a spec for that (or add it to the resource-indicators spec).


Personally, I see a lot of overlap even between the 'audience' and 
'resource' parameters. I'd really prefer we just have one parameter 
that can be either logical or specific. As outlined in this thread, 
'https://api.exampl.com' to me is a logical representation of the 
resource if the "real" endpoint(s) are 
"https://api.example.com/mail/user/inbox; 
<https://api.example.com/mail/user/inbox>, ...


Thanks,
George

On 2/7/19 10:16 AM, Hannes Tschofenig wrote:

Hi George,

  * I believe that since the latest draft of the resource
indicators spec [1] allows for abstract identifiers, and since
a URN is also a URI, you could easily use a URN syntax to
accomplish the use case outlined in your email.


After re-reading the token exchange draft I realized that we have
already defined a separate parameter for “abstract”, or logical,
names via the audience parameter. Here is the definition:

   audience

  OPTIONAL.  The logical name of the target service where the
client

  intends to use the requested security token.  This serves a

  purpose similar to the "resource" parameter, but with the client

  providing a logical name rather than a location.  Interpretation

  of the name requires that the value be something that both the

  client and the authorization server understand.  An OAuth client

  identifier, a SAML entity identifier [OASIS.saml-core-2.0-os

<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OASIS.saml-core-2.0-os>],
an

  OpenID Connect Issuer Identifier [OpenID.Core

<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OpenID.Core>],
or a URI are

  examples of things that might be used as "audience" parameter

  values.  Multiple "audience" parameters may be used to indicate

  that the issued token is intended to be used at the multiple

  audiences listed.  The "audience" and "resource" parameters
may be

  used together to indicate multiple target services with a mix of

  logical names and locations.

Ciao

Hannes

*From:*Ace  <mailto:ace-boun...@ietf.org>
*On Behalf Of * George Fletcher
*Sent:* Dienstag, 29. Janua

Re: [OAUTH-WG] [Ace] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[George Fletcher]

This is true... however, to my knowledge there is no support for this 
parameter outside of the token-exchange spec. Just because it is 
documented as an OAuth parameter I don't consider it usable in other 
contexts unless spec'd to do so. If we want to use 'audience' for 
logical audience names when binding audiences to tokens, then we need a 
spec for that (or add it to the resource-indicators spec).


Personally, I see a lot of overlap even between the 'audience' and 
'resource' parameters. I'd really prefer we just have one parameter that 
can be either logical or specific. As outlined in this thread, 
'https://api.exampl.com' to me is a logical representation of the 
resource if the "real" endpoint(s) are 
"https://api.example.com/mail/user/inbox;, ...


Thanks,
George

On 2/7/19 10:16 AM, Hannes Tschofenig wrote:


Hi George,

  * I believe that since the latest draft of the resource indicators
spec [1] allows for abstract identifiers, and since a URN is also
a URI, you could easily use a URN syntax to accomplish the use
case outlined in your email.

After re-reading the token exchange draft I realized that we have 
already defined a separate parameter for “abstract”, or logical, names 
via the audience parameter. Here is the definition:


audience

OPTIONAL.  The logical name of the target service where the client

intends to use the requested security token.  This serves a

purpose similar to the "resource" parameter, but with the client

providing a logical name rather than a location. Interpretation

of the name requires that the value be something that both the

client and the authorization server understand.  An OAuth client

identifier, a SAML entity identifier [OASIS.saml-core-2.0-os 
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OASIS.saml-core-2.0-os>], 
an


OpenID Connect Issuer Identifier [OpenID.Core 
<https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16#ref-OpenID.Core>], 
or a URI are


examples of things that might be used as "audience" parameter

values.  Multiple "audience" parameters may be used to indicate

that the issued token is intended to be used at the multiple

audiences listed.  The "audience" and "resource" parameters may be

used together to indicate multiple target services with a mix of

logical names and locations.

Ciao

Hannes

*From:*Ace  *On Behalf Of *George Fletcher
*Sent:* Dienstag, 29. Januar 2019 14:15
*To:* Ludwig Seitz ; a...@ietf.org; oauth@ietf.org
*Subject:* Re: [Ace] [OAUTH-WG] Shepherd write-up for 
draft-ietf-oauth-resource-indicators-01


Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec 
[1] allows for abstract identifiers, and since a URN is also a URI, 
you could easily use a URN syntax to accomplish the use case outlined 
in your email.


resource=urn:x-mydevices:temperatureSensorGroup4711

The spec currently outlines examples where the "resource identifier" 
is not a "single resource" in the context of a fully qualified API 
endpoint.


Another example, for an API like SCIM [RFC7644  
<https://tools.ietf.org/html/rfc7644>] that has

    multiple endpoints such as"https://apps.example.com/scim/Users;  
<https://apps.example.com/scim/Users>,

"https://apps.example.com/scim/Groups;  
<https://apps.example.com/scim/Groups>, and

"https://apps.example.com/scim/Schemas;  
<https://apps.example.com/scim/Schemas>  The client would use

"https://apps.example.com/scim/;  <https://apps.example.com/scim/>  as 
the resource so that the issued

    access token is valid for all the endpoints of the SCIM API.

Using "https://apps.example.com/scim; <https://apps.example.com/scim> 
is semantically equivalent to using "temperatureSensorGroup4711", at 
least to me:)


Thanks,
George

[1] https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

On 1/29/19 2:56 AM, Ludwig Seitz wrote:

On 28/01/2019 23:12, George Fletcher wrote:

I also don't know that this raises to the level of "concern"
but I find the parameter name of "req_aud" odd. Given that the
parameter in the resource-indicators spec is 'resource' why
not use a parameter name of 'audience'. That said, I have not
read the thread on the ACE working group list so there could
be very good reasons for the chosen name:)

I do think that there is a lot of overlap (in most cases)
between 'resource' and 'audience' and having two parameters
that cover a lot of the same semantics is going to be
confusing for developers. When calling an API at a resource
server, the 'audience' and the 'resource' are pretty
equivalent. Maybe in other use cases they are distinctly
separate

Re: [OAUTH-WG] [Ace] Resource, Audience, and req_aud

[George Fletcher]

+1 for rationalizing this! :)

On 2/7/19 10:24 AM, Hannes Tschofenig wrote:


Hi all,

after re-reading token exchange, the resource indicator, and the 
ace-oauth-params drafts I am wondering whether it is really necessary 
to have different functionality in ACE vs. in OAuth for basic parameters.


Imagine I use an Authorization Server and I support devices that use 
CoAP and HTTP.


 1. If a device uses CoAP then it has to use the req_aud parameter to
indicate to the authorization server that it wants to talk to a
specific resource server. It would either put a URI or a logical
name there.
 2. If a device uses HTTP then it has to use either the resource
parameter to indicate to the authorization server that it wants to
talk to a resource server, which is identified using a URI, or the
audience parameter, if it uses a logical name.

Ciao
Hannes

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.


___
Ace mailing list
a...@ietf.org
https://www.ietf.org/mailman/listinfo/ace


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