[OAUTH-WG] Re: New draft: OAuth Profile for Open Public Clients

[Vladimir Dzhuvinov]

Interesting draft. Having standard defined scopes for the most common operations of the underlying protocols is crucial, as Lisa points out. In OpenID Connect this was indispensable in making the whole thing complete, useful and interoperable. But where should these scopes get defined, if this is a spec for a general open public profile, and not email specific? ( as implied by the title )The dynamic client registration (DCR) will probably need implementers to consider measures against DoS attacks. One such measure could be the automatic expiration of client registrations that remain unused or where the client doesn't receive a token within a certain time.On 18 May 2024, at 1:12, Lisa Dusseault  wrote:Hi Neil,Thanks for publishing this, it's really great and will be most helpful.  The explanation of when the server uses DPoP and therefore when the client uses DPoP is pretty clear, but is it the intent that the HTTP-based protocols MUST use DPoP or is that really a RECOMMENDED for HTTP-based servers ?  Ie. did you intend "RECOMMEND use DPop" to mean  "MUST if you can but not if you can't" ? I know your document says that a separate document will define the scopes, but if you pull the scopes into this document ISTM it will really be a complete solution to many use cases. Without the scopes this does not stand alone and implementable and interoperable, whereas I think that just adding scopes will make it so.  (Also, I don't think the autodiscovery document will need to be a dependency but I may be wrong. ). You've clearly already thought about whether the scopes should be in this document or not,  can you expand on that?  I would love it if this went to the Standards Track.  Lisa DusseaultOn Thu, May 16, 2024 at 8:56 PM Neil Jenkins 40fastmailteam@dmarc.ietf.org> wrote:Hello all,I have published a draft document I'd like to introduce to the working group to consider: OAuth Profile for Open Public Clients.BackgroundI work for Fastmail, and we organised a conference at the end of last year with a bunch of the other major mailbox providers to work on interoperability and improving the open ecosystem. The topic most on everyone's minds was authentication.Unlike all the walled garden messaging systems, email remains to a large extent open. There are standard protocols (IMAP [RFC9051], SMTP [RFC5321], and more recently JMAP [RFC8620][RFC8621]) so you can have clients and servers built by different vendors, with no pre-existing relationship. Indeed, there are probably thousands of clients, and hundreds of thousands of servers out there. The situation is similar with contacts and calendars.Most server providers (and indeed many client authors) would like to move to a more secure authentication system, but at the moment basic auth is the only interoperable mechanism. Many clients have hardcoded Gmail/Microsoft OAuth flows (as those companies are big enough to force them to do so!), but this does not scale. At the conference we worked on building an OAuth profile that we believe can significantly increase security compared to the current status quo, to allow native Email/Contacts/Calendar clients to authenticate with an arbitrary server.I have talked to a few of you individually at the last couple of IETF meetings, and have finally had time to write up our proposal.Next stepsFirst of all, hopefully the working group can agree that this is a problem space that is significant, and worth addressing. If so, I hope it chooses to adopt this document as  a good starting point. I am not sure whether this should be a BCP rather than Standards Track — it deliberately does not introduce anything new, just combines a lot of existing standards in a specific way suitable for this use case.I will not be in Vancouver in person, but will join remotely. I do plan to be in Dublin. My current understanding is there are vendors such as Apple looking to start implementing something in this space in the nearish future, and obviously we would all like an agreed profile to ensure interoperability! They may be able to send someone to Vancouver.I would be very happy to bring on a co-author (or indeed largely pass it over to them, as I am very busy with other work at the moment, hence the delay in getting this draft together). I will certainly remain involved in any discussions around this area of course.I look forward to your feedback.Cheers,Neil.___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

___OAuth mailing list -- oauth@ietf.orgTo unsubscribe send an email to oauth-le...@ietf.org

smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Second WGLC for OAuth 2.0 Protected Resource Metadata

[Vladimir Dzhuvinov]

+1 in support for publication.

Vladimir Dzhuvinov

On 18/05/2024 08:45, Phillip Hunt wrote:

+1. I agree this is ready.

Phil

On May 17, 2024, at 1:35 PM, Giuseppe De Marco  
wrote:



+1 for publication

Il giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef 
 ha scritto:


All,

This is a _second_ *WG Last Call* for the *OAuth 2.0 Protected
Resource Metadata* document (the previous one was for v03.).
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-05.html


Please, review this document and reply on the mailing list if you
have any comments or concerns, by *May 29*.
If you reviewed the document and you do not have any comments or
concerns, it would be great if you can reply to this email
indicating that.

Regards,
  Rifaat & Hannes
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

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


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] WGLC for OAuth 2.0 Protected Resource Metadata

[Vladimir Dzhuvinov]

I have a question about the parameters: 
resource_signing_alg_values_supported, 
resource_encryption_alg_values_supported, 
resource_encryption_enc_values_supported.


I'm not sure how to interpret "content". Where the algorithms, if 
advertised, get to apply. Is this something that resources / 
applications will define, depending on the resource characteristics? If 
we take JWE for instance, it could be used for 3 things at least. To 
encrypt bearer JWTs to access the resource, in addition to encrypting 
request and response payloads.


Vladimir

On 27/03/2024 14:53, Rifaat Shekh-Yusef wrote:

All,

This is a *WG Last Call* for the *OAuth 2.0 Protected Resource 
Metadata* document.

https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-03.html

Please, review this document and reply on the mailing list if you have 
any comments or concerns, by *April 12*.


Regards,
  Rifaat & Hannes

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

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

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

[Vladimir Dzhuvinov]

+1 for the adoption so we can explore this as a WG document

+1 to Brian's comment to consider the application to tokens in general 
(unless the authors have plans for JWT / CWT specific features)


Vladimir Dzhuvinov

On 03/10/2023 00:10, Brian Campbell wrote:

I support adoption.

I do think the document would be more appropriately scoped with more 
focus on the status list itself and less so on the JWT/CWT signed 
representations thereof. As such, I'd suggest maybe using a less 
specific docname without the jwt-cwt bit if/when it moves to a WG 
draft. Something like draft-ietf-oauth-token-status-list.







On Sat, Sep 30, 2023 at 6:53 AM Rifaat Shekh-Yusef 
 wrote:


All,

This is an official call for adoption for the *JWT and CWT Status
List* draft:
https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/

Please, reply *on the mailing list *and let us know if you are in
*favor *or*against *adopting this draft as WG document, by *Oct 13th*.

Regards,
 Rifaat & Hannes
___
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

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

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

[Vladimir Dzhuvinov]

I support adoption.

Vladimir Dzhuvinov

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

All,

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

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

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


Regards,
 Rifaat & Hannes


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

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

Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification

[Vladimir Dzhuvinov]

+1 in support for this complementary draft.

Vladimir Dzhuvinov

On 26/05/2023 16:55, Oliver Terbu wrote:

Dear all,

I hope this email finds you well. I am writing to introduce 
"SD-JWT-based Verifiable Credentials with JSON payloads” (SD-JWT VC):


https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/

This proposal builds upon the existing SD-JWT specification by the 
OAuth WG and aims to address certain gaps and provide specific 
guidance for utilizing SD-JWT in the context of Verifiable 
Credentials. For example, while SD-JWT defines how to implement 
selective disclosure in JWTs (an important building block in many 
Verifiable Credential use cases), it is not opinionated about the 
specific JWT Claim Sets in the payload to represent Verifiable 
Credentials and used with HB-JWT.


As you may be aware, the SD-JWT specification has already been adopted 
by the OAuth WG and has gained significant traction within the 
industry. However, the SD-JWT specification does not provide explicit 
guidance on using SD-JWT for Verifiable Credentials.


The eIDAS 2.0 Architecture Reference Framework (ARF) has expressed a 
keen interest in utilizing SD-JWT for Verifiable Credentials, and 
SD-JWT VC became one of the two core credential formats of the 
European Digital Wallet (EUDIW):


https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework

Verifiable Credentials play a crucial role in enhancing digital trust 
and enabling secure identity interactions in various domains. To 
ensure the seamless integration of SD-JWT into the eIDAS ARF and 
similar initiatives, it is essential to address the existing gaps in 
the SD-JWT specification specifically relevant to Verifiable Credentials.


As a general-purpose format, SD-JWT itself is not the right place to 
define these kinds of guidelines. The SD-JWT VC draft proposes to fill 
these gaps by defining additional requirements, clarifying 
ambiguities, and providing concrete guidelines for utilizing SD-JWT in 
the context of Verifiable Credentials. Since SD-JWT VC and SD-JWT are 
closely related, we propose to develop this specification in the OAuth 
working group.


Your support and endorsement of this proposal would significantly 
contribute to the advancement of Verifiable Credentials.


If you have any questions or require additional information regarding 
the "SD-JWT VC" specification or its potential impact, please do not 
hesitate to reach out.

I’m looking forward to your feedback!

Oliver Terbu

--
Director of Identity Standards, Spruce Systems, Inc.
oliver.te...@spruceid.com

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

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

Re: [OAUTH-WG] OAuth2 Client Discovery

[Vladimir Dzhuvinov]

Hi Tobias,


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



This looks roughly like this:

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

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

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


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



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



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




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




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




~ Vladimir


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

Hi All,

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


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

Below is the drafts current abstract for context:

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


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


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


Thanks,

Mattr website 







*Tobias Looker*

MATTR
CTO

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

Mattr website 





Mattr on LinkedIn 





Mattr on Twitter 

Re: [OAUTH-WG] Call for adoption: Cross-Device Flows

[Vladimir Dzhuvinov]

+1 in support for adoption.

Vladimir Dzhuvinov

On 15/11/2022 16:43, Rifaat Shekh-Yusef wrote:

All,

During the IETF meeting last week, there was a strong support for 
the adoption of the following document as a WG document:

https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/

This is to start a call for adoption for this document.
Please, provide your feedback on the mailing list on whether you 
support the adoption of this document as a WG or not, by *Nov 29th*.


Regards,
 Rifaat & Hannes



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

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

Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

[Vladimir Dzhuvinov]

Hi Dima,

A published RFC cannot be extended to specify new things, only have 
errata added it. The OAuth 2.1 spec is still a draft in the works.


What do you think is a suitable default value for a 
code_challenge_method client reg parameter?


From the perspective of an OAuth 2.0 deployment it could be none (i.e. 
no PKCE) or S256, in the latter case a client will need to explicitly 
opt out of it, but how exactly?


From the perspective of an OAuth 2.1 deployment it would be S256.



Vladimir Dzhuvinov

On 09/10/2022 02:33, Dima Postnikov wrote:

Hi Vladimir.

Client registration parameter sounds like a good idea to me.

In terms of which document this goes to I wonder if PKCE RFC7636 
could be updated to add this. This way ecosystems using PKCE in OAuth 
2.0 could benefit from this too.


Thanks

Dima


On Sat, Oct 8, 2022 at 9:27 PM Vladimir Dzhuvinov 
 wrote:


Thanks for chiming in Dima.

Do you reckon it's a good idea to define a code_challenge_method
client reg parameter in the OAuth 2.1 spec?

To enable 2.0 -> 2.1 transitions and also give people a concrete
and standard compliant way to implement the "REQUIRED or
RECOMMENDED" in the OAuth 2.1 spec for code_challenge.

Another spec that deals with PKCE is the OAuth BCP, but to me
that's not a optimal place to define a new parameter.


Vladimir Dzhuvinov


On 08/10/2022 04:31, Dima Postnikov wrote:

Hi Vladimir,

Similar issue exists in CDR (Australian Open Banking). PAR and
PKCE was added as mandatory to FAPI 1 Advanced profile.

There was a transition period when AS had to support both
(potentially).

Also if the same AS is used outside of CDR, this dual support
would continue for some implementations.

I don't think this was solved, so your client registration
parameter makes sense.



On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov
 wrote:

Has anyone faced the issue how an AS can handle a mix of
OAuth 2.0 and
2.1 clients regarding PKCE enforcement?

The new OAuth 2.1 spec makes PKCE required, which is a good
security
measure and fine for an AS where all clients are ready to
comply with
the upgrade. In practice however, it's common for AS
deployments to have
a mix of legacy 2.0 and 2.1 clients, and at present OAuth
doesn't have a
standard client registration parameter, e.g.
code_challenge_method, to
lock a client into using PKCE.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1

RFC 8414 defined the code_challenge_methods_supported
metadata for
servers. It would be useful if deployments had a
corresponding parameter
for the clients.

https://www.rfc-editor.org/rfc/rfc8414

~ Vladimir

    -- 
    Vladimir Dzhuvinov


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


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

Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

[Vladimir Dzhuvinov]

Hi Brock,

Right, so it's already happening :)

My honest preference is to give people a standard code_challenge_method 
client reg parameter for this job and eliminate guesswork.


~ Vladimir


Vladimir Dzhuvinov

On 08/10/2022 05:38, Brock Allen wrote:

> Has anyone faced the issue how an AS can handle a mix of OAuth 2.0 and
2.1 clients regarding PKCE enforcement?

In Duende IdentityServer we make this a per-client setting. That makes 
for a very simple solution to the problem.


-Brock


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

Re: [OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

[Vladimir Dzhuvinov]

Thanks for chiming in Dima.

Do you reckon it's a good idea to define a code_challenge_method client 
reg parameter in the OAuth 2.1 spec?


To enable 2.0 -> 2.1 transitions and also give people a concrete and 
standard compliant way to implement the "REQUIRED or RECOMMENDED" in the 
OAuth 2.1 spec for code_challenge.


Another spec that deals with PKCE is the OAuth BCP, but to me that's not 
a optimal place to define a new parameter.



Vladimir Dzhuvinov


On 08/10/2022 04:31, Dima Postnikov wrote:

Hi Vladimir,

Similar issue exists in CDR (Australian Open Banking). PAR and PKCE 
was added as mandatory to FAPI 1 Advanced profile.


There was a transition period when AS had to support both (potentially).

Also if the same AS is used outside of CDR, this dual support would 
continue for some implementations.


I don't think this was solved, so your client registration parameter 
makes sense.




On Wed, Oct 5, 2022 at 5:43 PM Vladimir Dzhuvinov 
 wrote:


Has anyone faced the issue how an AS can handle a mix of OAuth 2.0
and
2.1 clients regarding PKCE enforcement?

The new OAuth 2.1 spec makes PKCE required, which is a good security
measure and fine for an AS where all clients are ready to comply with
the upgrade. In practice however, it's common for AS deployments
to have
a mix of legacy 2.0 and 2.1 clients, and at present OAuth doesn't
have a
standard client registration parameter, e.g.
code_challenge_method, to
lock a client into using PKCE.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1

RFC 8414 defined the code_challenge_methods_supported metadata for
servers. It would be useful if deployments had a corresponding
parameter
for the clients.

https://www.rfc-editor.org/rfc/rfc8414

~ Vladimir

-- 
Vladimir Dzhuvinov


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


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

[OAUTH-WG] How to enforce PKCE in authorization servers with a mix OAuth 2.0 and 2.1 clients?

[Vladimir Dzhuvinov]

Has anyone faced the issue how an AS can handle a mix of OAuth 2.0 and 
2.1 clients regarding PKCE enforcement?


The new OAuth 2.1 spec makes PKCE required, which is a good security 
measure and fine for an AS where all clients are ready to comply with 
the upgrade. In practice however, it's common for AS deployments to have 
a mix of legacy 2.0 and 2.1 clients, and at present OAuth doesn't have a 
standard client registration parameter, e.g. code_challenge_method, to 
lock a client into using PKCE.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-02#section-4.1.1

RFC 8414 defined the code_challenge_methods_supported metadata for 
servers. It would be useful if deployments had a corresponding parameter 
for the clients.


https://www.rfc-editor.org/rfc/rfc8414

~ Vladimir

--
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] DPoP - Impementations

[Vladimir Dzhuvinov]

Hello Rifaat,

We are very pleased with DPoP and hope to see more people using it in 
future.


DPoP in the OSS Nimbus OAuth 2.0 / OIDC Java SDK:

https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/dpop

In the c2id server:

https://connect2id.com/products/server/docs/datasheet#dpop

Vladimir Dzhuvinov

On 11/08/2022 00:39, Rifaat Shekh-Yusef wrote:

All,

As part of the shepherd write-up for the *DPoP* document, we are 
looking for information about implementations of this draft.

https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, reply to this email on the mailing list with any 
implementations that you are aware of to support this document.


Regards,
 Rifaat & Hannes

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

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

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

Thanks Brian for your response.

Do you think DPoP should have an own token type URI registered?

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri

I did not think about the possibility of having the DPoP proof and the 
token value put together in the subject/actor_token parameter. It makes 
good sense because the proof and the token can be considered 
inseparable, i.e. the "complete token".


The DPoP JWT has a well defined syntax, so I am now thinking of 
appending the token to the DPoP JWT with a dot (.) delimiter. This is 
sufficient to make the new string parseable and thus solve the case. 
Having a std DPoP token type URI would be nice for clients to hint to 
the AS that the subject/actor_token is a combination of DPoP proof and 
access token.


Vladimir

Vladimir Dzhuvinov

On 18/07/2022 21:46, Brian Campbell wrote:
While there are potentially more tokens involved in a RFC 8693 token 
exchange, it's still a single client and it's not evident (to me 
anyway at this point) that there's sufficient need to give it distinct 
DPoP treatment beyond other token endpoint interaction 
<https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-10.html#name-dpop-access-token-request>s. 
Should the need arise more, I'd suggest maybe considering having the 
new token type define how the token and associated proof be conveyed 
together as the value of the subject/actor_token parameter rather than 
introducing new parameters.


On Mon, Jul 18, 2022 at 9:34 AM Vladimir Dzhuvinov 
 wrote:


I find the token exchange RFC to be quite flexible, it allows the
subject_token, actor_token and the output token to be of any type,
and there is a mechanism to define (register) new
urn:ietf:params:oauth:token-type values. The only concrete need is
to define a way to pass the accompanying DPoP proof. I don't think
that could have been anticipated at the time when the exchange
spec was devised. And the token exchange spec is not explicit in
prohibiting extensions.

    Vladimir

Vladimir Dzhuvinov

On 18/07/2022 17:03, Warren Parad wrote:

I agree this is a problem, but as I see it as a problem for Token
Exchange, and the lack of flexibility in that standard, it does
not make sense to add to the DPoP spec.

On Mon, Jul 18, 2022 at 3:33 PM Vladimir Dzhuvinov
 wrote:

I would like to resurrect this thread and propose a new
section to the current DPoP draft which changes nothing in
regard to DPoP itself, only adds new parameters to enable
DPoP with OAuth 2.0 token exchange (RFC 8693):

https://datatracker.ietf.org/doc/html/rfc8693

Why?

Token exchange lets a client submit a subject_token (and
potentially actor_token) to obtain a new token from the AS.

If the submitted token(s) and the minted token are DPoP bound
there is a need to submit a DPoP proof for each one:

  * A DPoP proof for the subject_token
  * Potentially a DPoP proof for the actor_token (if there is
one)
  * A DPoP proof for the token that is going to be minted by
the AS

At present the DPoP spec defines the DPoP header in such a
way that only one DPoP proof may be submitted.


The proposal:

A new section "DPoP with Token Exchange":

Specifies the following new optional form request parameters
for use in the token exchange grant, so that any DPoP proofs
can be submitted together with the subject_token /
actor_token as form parameters:

subject_token_dpop - To pass the DPoP proof for a
subject_token that is DPoP bound

actor_token_dpop - To pass the DPoP proof for an actor_token
that is DPoP bound


(the existing std token exchange params can be seen here
https://datatracker.ietf.org/doc/html/rfc8693#section-2.1 )


Registration of a new token type identifier to indicate the
token is a DPoP access token:

https://datatracker.ietf.org/doc/html/rfc8693#section-3

urn:ietf:params:oauth:token-type:dpop_access_token
   Indicates that the token is an OAuth 2.0 DPoP bound access token 
issued by the given authorization server.


I hope it's not too late to include this addition to the DPoP
spec. The token exchange grant is standard and is seeing use.
With the introduction of DPoP it is likely such tokens will
become involved in token exchanges. We tried a work around
where the client uses a single DPoP proof for the submitted
tokens and the one to be minted, but this has issues,
including potential security issues. So I've come to the
conclusion that a spec change of some sort is the proper way
to solve this. The proposed solution has no effect on DPoP
core and it preserves the existin

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

I find the token exchange RFC to be quite flexible, it allows the 
subject_token, actor_token and the output token to be of any type, and 
there is a mechanism to define (register) new 
urn:ietf:params:oauth:token-type values. The only concrete need is to 
define a way to pass the accompanying DPoP proof. I don't think that 
could have been anticipated at the time when the exchange spec was 
devised. And the token exchange spec is not explicit in prohibiting 
extensions.


Vladimir

Vladimir Dzhuvinov

On 18/07/2022 17:03, Warren Parad wrote:
I agree this is a problem, but as I see it as a problem for Token 
Exchange, and the lack of flexibility in that standard, it does not 
make sense to add to the DPoP spec.


On Mon, Jul 18, 2022 at 3:33 PM Vladimir Dzhuvinov 
 wrote:


I would like to resurrect this thread and propose a new section to
the current DPoP draft which changes nothing in regard to DPoP
itself, only adds new parameters to enable DPoP with OAuth 2.0
token exchange (RFC 8693):

https://datatracker.ietf.org/doc/html/rfc8693

Why?

Token exchange lets a client submit a subject_token (and
potentially actor_token) to obtain a new token from the AS.

If the submitted token(s) and the minted token are DPoP bound
there is a need to submit a DPoP proof for each one:

  * A DPoP proof for the subject_token
  * Potentially a DPoP proof for the actor_token (if there is one)
  * A DPoP proof for the token that is going to be minted by the AS

At present the DPoP spec defines the DPoP header in such a way
that only one DPoP proof may be submitted.


The proposal:

A new section "DPoP with Token Exchange":

Specifies the following new optional form request parameters for
use in the token exchange grant, so that any DPoP proofs can be
submitted together with the subject_token / actor_token as form
parameters:

subject_token_dpop - To pass the DPoP proof for a subject_token
that is DPoP bound

actor_token_dpop - To pass the DPoP proof for an actor_token that
is DPoP bound


(the existing std token exchange params can be seen here
https://datatracker.ietf.org/doc/html/rfc8693#section-2.1 )


Registration of a new token type identifier to indicate the token
is a DPoP access token:

https://datatracker.ietf.org/doc/html/rfc8693#section-3

urn:ietf:params:oauth:token-type:dpop_access_token
   Indicates that the token is an OAuth 2.0 DPoP bound access token 
issued by the given authorization server.


I hope it's not too late to include this addition to the DPoP
spec. The token exchange grant is standard and is seeing use. With
the introduction of DPoP it is likely such tokens will become
involved in token exchanges. We tried a work around where the
client uses a single DPoP proof for the submitted tokens and the
one to be minted, but this has issues, including potential
security issues. So I've come to the conclusion that a spec change
of some sort is the proper way to solve this. The proposed
solution has no effect on DPoP core and it preserves the existing
token exchange semantics.


Vladimir

    Vladimir Dzhuvinov

On 25/06/2022 15:23, Vladimir Dzhuvinov wrote:


Hi Warren,

The case looks like this:

  * An OAuth client registered with AS1 for code flow, with AS2
for token exchange
  * API1 secured by AS1, API2 secured by AS2
  * For API1 the client obtains DPoP tokens from AS1
  * For API2 the client presents DPoP token from AS1 as grant at
AS2 to obtain its own DPoP token (AS2 trusts selected AS1
token scopes for this)

So we have a case where the token endpoint at AS2 needs once a
DPoP proof for the submitted access token (in the subject_token
form parameter), and a second time to bind the token that is
going to be issued. I.e. a situation where the token endpoint is
also "addressed" as a DPoP aware protected resource.

If only one DPoP HTTP header is permitted one work around I see
is to insist on a single DPoP proof for both jobs, by including
the "ath" claim in the proof to the AS2 token endpoint and
requiring the client to use the same JWK with both ASes. Another
possibility is to include the DPoP proof in the form parameters
alongside the subject_token, but this will require a spec change.

Vladimir Dzhuvinov
On 25/06/2022 13:33, Warren Parad wrote:

What's the flow here? Assuming we are talking about RFC 8693,
what's the situation where you would need to do a token
exchange, and you actually have access to the subject's DPoP
key? If you have access to the subject's key, then you are the
subject and can request a new token. Or am I missing something
fundamental here?

Also, according to the RFC, the request must be made with client
authentication

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

I would like to resurrect this thread and propose a new section to the 
current DPoP draft which changes nothing in regard to DPoP itself, only 
adds new parameters to enable DPoP with OAuth 2.0 token exchange (RFC 8693):


https://datatracker.ietf.org/doc/html/rfc8693

Why?

Token exchange lets a client submit a subject_token (and potentially 
actor_token) to obtain a new token from the AS.


If the submitted token(s) and the minted token are DPoP bound there is a 
need to submit a DPoP proof for each one:


 * A DPoP proof for the subject_token
 * Potentially a DPoP proof for the actor_token (if there is one)
 * A DPoP proof for the token that is going to be minted by the AS

At present the DPoP spec defines the DPoP header in such a way that only 
one DPoP proof may be submitted.



The proposal:

A new section "DPoP with Token Exchange":

Specifies the following new optional form request parameters for use in 
the token exchange grant, so that any DPoP proofs can be submitted 
together with the subject_token / actor_token as form parameters:


subject_token_dpop - To pass the DPoP proof for a subject_token that is 
DPoP bound


actor_token_dpop - To pass the DPoP proof for an actor_token that is 
DPoP bound



(the existing std token exchange params can be seen here 
https://datatracker.ietf.org/doc/html/rfc8693#section-2.1 )



Registration of a new token type identifier to indicate the token is a 
DPoP access token:


https://datatracker.ietf.org/doc/html/rfc8693#section-3

   urn:ietf:params:oauth:token-type:dpop_access_token
  Indicates that the token is an OAuth 2.0 DPoP bound access token issued 
by the given authorization server.


I hope it's not too late to include this addition to the DPoP spec. The 
token exchange grant is standard and is seeing use. With the 
introduction of DPoP it is likely such tokens will become involved in 
token exchanges. We tried a work around where the client uses a single 
DPoP proof for the submitted tokens and the one to be minted, but this 
has issues, including potential security issues. So I've come to the 
conclusion that a spec change of some sort is the proper way to solve 
this. The proposed solution has no effect on DPoP core and it preserves 
the existing token exchange semantics.



Vladimir

Vladimir Dzhuvinov

On 25/06/2022 15:23, Vladimir Dzhuvinov wrote:


Hi Warren,

The case looks like this:

  * An OAuth client registered with AS1 for code flow, with AS2 for
token exchange
  * API1 secured by AS1, API2 secured by AS2
  * For API1 the client obtains DPoP tokens from AS1
  * For API2 the client presents DPoP token from AS1 as grant at AS2
to obtain its own DPoP token (AS2 trusts selected AS1 token scopes
for this)

So we have a case where the token endpoint at AS2 needs once a DPoP 
proof for the submitted access token (in the subject_token form 
parameter), and a second time to bind the token that is going to be 
issued. I.e. a situation where the token endpoint is also "addressed" 
as a DPoP aware protected resource.


If only one DPoP HTTP header is permitted one work around I see is to 
insist on a single DPoP proof for both jobs, by including the "ath" 
claim in the proof to the AS2 token endpoint and requiring the client 
to use the same JWK with both ASes. Another possibility is to include 
the DPoP proof in the form parameters alongside the subject_token, but 
this will require a spec change.


Vladimir Dzhuvinov
On 25/06/2022 13:33, Warren Parad wrote:
What's the flow here? Assuming we are talking about RFC 8693, what's 
the situation where you would need to do a token exchange, and you 
actually have access to the subject's DPoP key? If you have access to 
the subject's key, then you are the subject and can request a new 
token. Or am I missing something fundamental here?


Also, according to the RFC, the request must be made with client 
authentication, you don't need DPoP, because if the client's 
credentials are compromised, you have a different problem. Unless the 
goal is to DPoP instead of client credentials, in which case, I think 
I'm back to the previous question.


On Sat, Jun 25, 2022 at 12:19 PM Vladimir Dzhuvinov 
 wrote:


I have a question to the DPoP spec authors - do you have a
suggestion how to approach a token exchange case where the client
requests a DPoP token and the submitted subject(actor)_token is /
are also DPoP bound?

My first thought was to simply let the client send two DPoP JWTs,
one for the submitted token and another for the requested token,
and then find a way in the AS to figure out which is which, but
then I found this in section 4.3.1:


To validate a DPoP proof, the receiving server MUST ensure that
that there is not more than one |DPoP| HTTP request header field,


Thanks,

Vladimir

-- 
Vladimir Dzhuvinov


___
OAuth mailing list
OAuth@iet

Re: [OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

Hi Warren,

The case looks like this:

 * An OAuth client registered with AS1 for code flow, with AS2 for
   token exchange
 * API1 secured by AS1, API2 secured by AS2
 * For API1 the client obtains DPoP tokens from AS1
 * For API2 the client presents DPoP token from AS1 as grant at AS2 to
   obtain its own DPoP token (AS2 trusts selected AS1 token scopes for
   this)

So we have a case where the token endpoint at AS2 needs once a DPoP 
proof for the submitted access token (in the subject_token form 
parameter), and a second time to bind the token that is going to be 
issued. I.e. a situation where the token endpoint is also "addressed" as 
a DPoP aware protected resource.


If only one DPoP HTTP header is permitted one work around I see is to 
insist on a single DPoP proof for both jobs, by including the "ath" 
claim in the proof to the AS2 token endpoint and requiring the client to 
use the same JWK with both ASes. Another possibility is to include the 
DPoP proof in the form parameters alongside the subject_token, but this 
will require a spec change.


Vladimir Dzhuvinov

On 25/06/2022 13:33, Warren Parad wrote:
What's the flow here? Assuming we are talking about RFC 8693, what's 
the situation where you would need to do a token exchange, and you 
actually have access to the subject's DPoP key? If you have access to 
the subject's key, then you are the subject and can request a new 
token. Or am I missing something fundamental here?


Also, according to the RFC, the request must be made with client 
authentication, you don't need DPoP, because if the client's 
credentials are compromised, you have a different problem. Unless the 
goal is to DPoP instead of client credentials, in which case, I think 
I'm back to the previous question.


On Sat, Jun 25, 2022 at 12:19 PM Vladimir Dzhuvinov 
 wrote:


I have a question to the DPoP spec authors - do you have a
suggestion how to approach a token exchange case where the client
requests a DPoP token and the submitted subject(actor)_token is /
are also DPoP bound?

My first thought was to simply let the client send two DPoP JWTs,
one for the submitted token and another for the requested token,
and then find a way in the AS to figure out which is which, but
then I found this in section 4.3.1:


To validate a DPoP proof, the receiving server MUST ensure that
that there is not more than one |DPoP| HTTP request header field,


Thanks,

Vladimir

    -- 
    Vladimir Dzhuvinov


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


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

[OAUTH-WG] DPoP with token exchange where the subject_token and / or actor_token is also DPoP bound

[Vladimir Dzhuvinov]

I have a question to the DPoP spec authors - do you have a suggestion 
how to approach a token exchange case where the client requests a DPoP 
token and the submitted subject(actor)_token is / are also DPoP bound?


My first thought was to simply let the client send two DPoP JWTs, one 
for the submitted token and another for the requested token, and then 
find a way in the AS to figure out which is which, but then I found this 
in section 4.3.1:


To validate a DPoP proof, the receiving server MUST ensure that that 
there is not more than one |DPoP| HTTP request header field,


Thanks,

Vladimir

--
Vladimir Dzhuvinov


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

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

[Vladimir Dzhuvinov]

+1 for adoption

Vladimir Dzhuvinov

On 26/04/2022 13:46, Rifaat Shekh-Yusef wrote:

This is a call for adoption for the *Step-up Authentication* document
https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/

Please, provide your feedback on the mailing list by *May 10th*.

Regards,
 Rifaat & Hannes


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

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

Re: [OAUTH-WG] OAuth 2.0 Rich Authorization Requests (RAR): Implementation Status

[Vladimir Dzhuvinov]

Hello Hannes,

The RAR spec has been stable for some time now and received production 
implementations in several different industries.


https://connect2id.com/products/server/docs/datasheet#rar

~Vladimir

--
Vladimir Dzhuvinov


On 06/04/2022 16:46, Hannes Tschofenig wrote:


Hi all,

I am working on the shepherd writeup for the RAR document and the IESG 
is interested to hear about the implementation status of this 
specification.


What implementations are available that use the RAR functionality or 
are vendors planning to implement this specification?


Ciao

Hannes


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

Re: [OAUTH-WG] WGLC for DPoP Document

[Vladimir Dzhuvinov]

I support DPoP publication

--
Vladimir Dzhuvinov

On 28/03/2022 15:01, Rifaat Shekh-Yusef wrote:

All,

As discussed during the IETF meeting in *Vienna* last week, this is a 
*WG Last Call *for the *DPoP* document:

https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/

Please, provide your feedback on the mailing list by April 11th.

Regards,
 Rifaat & Hannes


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


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

[OAUTH-WG] draft-bertocci-oauth-step-up-authn-challenge - how can an RS signal re-authenticate user, without concern for ACR?

[Vladimir Dzhuvinov]

Given the suggested protocol for step up (I just watched the talk in 
Vienna, thanks Vittorio & Brian) - how could an RS signal that it simply 
wants the end-user re-authenticated, without being concerned about the ACR?


Vladimir

--
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

[Vladimir Dzhuvinov]

+1 in support for publication.

The Nimbus JWT lib was recently updated to match the 01 spec with the 
hash alg in the URN.


Vladimir Dzhuvinov

On 21/02/2022 15:12, Rifaat Shekh-Yusef wrote:

All,

Mike and Kristina made the necessary changes to address all the great 
comments received during the initial WGLC.


This is a *second* WG Last Call for this document to make sure that 
the WG has a chance to review these changes:

https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *March 7th*.

Regards,
 Rifaat & Hannes

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

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Vladimir Dzhuvinov]

The original JWK thumbprint RFC 7638 essentially describes the method 
for composing the hash input from a JWK and that the output is base64url 
encoded. SHA-256 is mentioned, but there is no default implied hash 
function. This leaves it to applications / other specs to determine.


https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This 
will make things more explicit and self-contained.


What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov

On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume 
it is SHA-256, but it should either say that is the only algorithm 
allowed or perhaps encode the hash algorithm into the URI. Otherwise 
the value is ambiguous.


Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share 
attacks, as well as issues due to malleable signature schemes or key 
exchange schemes - where the same proof of identity is valid under 
many public keys. The security considerations should mention these 
issues, and potential suggest countermeasures (eg including the full 
public key JWK in the input to be signed etc).


— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef  
wrote:



All,

The *JWK Thumbprint URI *document is a simple and 
straightforward specification.


This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *Feb 16th*.

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] WGLC for JWK Thumbprint URI document

[Vladimir Dzhuvinov]

+1 in support for a jkt URI RFC

Vladimir Dzhuvinov

On 02/02/2022 16:50, Mike Jones wrote:


Thanks Rifaat,

I support publication of the specification.

-- Mike

*From:* OAuth  *On Behalf Of * Rifaat Shekh-Yusef
*Sent:* Wednesday, February 2, 2022 4:19 AM
*To:* oauth 
*Subject:* [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The *JWK Thumbprint URI *document is a simple and 
straightforward specification.


This is a WG Last Call for this document:

https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *Feb 16th*.

Regards,

 Rifaat & Hannes


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

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

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

[Vladimir Dzhuvinov]

+1 in support for adoption

Vladimir Dzhuvinov

On 13/01/2022 16:26, 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

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

Re: [OAUTH-WG] can a resource server provide indications about expected access tokens?

[Vladimir Dzhuvinov]

Hi Nikos,

The "error_description" can be used to explain the expected token issuer 
and other facts to client developers.


https://datatracker.ietf.org/doc/html/rfc6750#section-3

If you want to give client software the ability to respond 
programmatically this will require some sort of a proprietary extension.


Vladimir

Vladimir Dzhuvinov

On 11/12/2021 12:35, Nikos Fotiou wrote:

Hi,

I have a use case where a resource server is protected  and can only be accessed if a JWT is presented. Is 
there any way for the server to "indicate" the "expected" format of the JWT. For example, 
 respond to unauthorized requests with something that would be translated into "I expect tokens form iss 
X with claims [A,B,C]"

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


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

[OAUTH-WG] DPoP 03 - introspection - token_type?

[Vladimir Dzhuvinov]

The token introspection RFC defines the optional "token_type" member and 
I just noticed that draft-ietf-oauth-dpop-03 doesn't mention it.


https://datatracker.ietf.org/doc/html/rfc7662#section-2.2

Would it be sensible to mention that if the "token_type" gets set in a 
introspection response, it must be "DPoP"?


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2

Vladimir

--
Vladimir Dzhuvinov




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

Re: [OAUTH-WG] Robert Wilton's No Objection on draft-ietf-oauth-jwt-introspection-response-11: (with COMMENT)

[Vladimir Dzhuvinov]

Thank you Robert. We'll consider the proposed change to the must 
language in the privacy section.


Vladimir Dzhuvinov

On 28/06/2021 17:14, Robert Wilton via Datatracker wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



--
COMMENT:
--

I still believe that using non 2119 language (i.e., "must" rather than "MUST")
would be better for the privacy section, but won't block the document on this
minor point.







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

Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

[Vladimir Dzhuvinov]

The spec is fine, we've had it implemented for some time now and support 
its publication.


+1 to Brian's comment. I suppose it suffices to say the iss parameter is 
redundant when JARM is used as JARM provides the same countermeasure. I 
found the normative text about what JARM allows or disallows (or have 
text that reads like normative) problematic, the JARM spec should remain 
the place for this.


Thanks for this work Karsten. Also my thanks to Daniel.

Vladimir

On 21/05/2021 00:00, Brian Campbell wrote:

Thanks Karsten,

That's moving in the right direction. But I think the last sentence is 
still too strong and maybe prone to misunderstanding given it's not 
100% obvious in the JARM case what exactly constitutes an 
authorization response parameter.


I'd say the last sentence could just be dropped altogether. Or maybe 
changed to something like this, "Therefore, an additional iss 
parameter outside the JWT is unneeded when JARM is used."



On Wed, May 19, 2021 at 12:45 AM Karsten Meyer zu Selhausen 
> wrote:


Hi Brian,

thank you for your feedback.

I agree that the language is too strong here. What do you think
about this new note?


Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] defines a mechanism that conveys all authorization
response parameters in a JWT. This JWT contains an iss claim that
provides the same protection if it is validated as described in
Section 2.4. Therefore, an additional iss authorization response
parameter as defined by this document MUST NOT be used when JARM
is used.


Best regards,
Karsten

On 15.05.2021 00:35, Brian Campbell wrote:

Overall it looks pretty good to me.
One little nit is that I don't love this text from the end of sec
2.4 that talks about JARM:

'Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] forbids the use of additional parameters in the
authorization response. Therefore, the iss parameter MUST NOT be
used when JARM is used. However, JARM responses contain an iss
claim that provides the same protection if it is validated as
described in Section 2.4.'

JARM doesn't exactly forbid additional parameters but rather just
wraps up all the authorization response parameters as claims in a
JWT which is itself sent as a single form/query/fragment
parameter. So really the iss authorization response parameter of
this draft is still sent as a claim of the JARM JWT. It just
happens to be the same as the iss claim value that JARM is
already including.

On Sat, May 1, 2021 at 2:47 PM Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> wrote:

All,

We have not seen any comments on this document.
Can you please review the document and provide feedback, or
indicate that you have reviewed the document and have no
concerns.

Regards,
 Rifaat & Hannes


On Thu, Apr 15, 2021 at 3:04 AM Karsten Meyer zu Selhausen
mailto:karsten.meyerzuselhau...@hackmanit.de>> wrote:

Hi all,

the latest version of the security BCP references
draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to
mix-up attacks.

There have not been any concerns with the first WG draft
version so far:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/


I would like to ask the WG if there are any comments on
or concerns with the current draft version.

Otherwise I hope we can move forward with the next steps
and hopefully finish the draft before/with the security BCP.

Best regards,
Karsten

-- 
Karsten Meyer zu Selhausen

Senior IT Security Consultant
Phone:  +49 (0)234 / 54456499
Web:https://hackmanit.de    | IT 
Security Consulting, Penetration Testing, Security Training

Is your OAuth or OpenID Connect client vulnerable to the severe 
impacts of mix-up attacks? Learn how to protect your client in our latest blog 
post on single sign-on:

https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
  


Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj 
Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz

___
OAuth mailing list
OAuth@ietf.org 

Re: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS)

[Vladimir Dzhuvinov]

Hi all,


In preparation for a new v11 of the draft the language regarding the 
adherence to privacy regulations was updated along the lines of Roman's 
suggestion (thanks for that!):



"""

The token introspection response can be used to transfer personal 
identifiable information (PII) from the AS to the RS. The AS MUST 
conform to legal and jurisdictional constraints for the data transfer 
before any data is released to a particular RS. The details and 
determining of these constraints varies by jurisdiction and is outside 
the scope of this document.


"""


The diff for this edit is here:

https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response/commit/48911a1afff9f3120773a157c4e14cbf3aa9f3de#diff-c4d976e7848e055731f69102bf2d6e4e7cf7d997efc1f202eb3b940d44746274


The current doc:

https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response/blob/master/draft-ietf-oauth-jwt-introspection-response.xml


Vladimir

Vladimir Dzhuvinov

On 04/02/2021 16:40, Roman Danyliw wrote:

Hi! Rob!


-Original Message-
From: OAuth  On Behalf Of Robert Wilton via
Datatracker
Sent: Thursday, February 4, 2021 6:20 AM
To: The IESG 
Cc: oauth-cha...@ietf.org; draft-ietf-oauth-jwt-introspection-
respo...@ietf.org; oauth@ietf.org
Subject: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt-
introspection-response-10: (with DISCUSS)

Robert Wilton has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-10: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

Hi,

Thank you for this document.

I have a  couple of process related questions regarding the legal aspects
considered in chapter 9 on privacy that I would like to discuss with the other
ADs on the telechat (hence raising it as a Discuss).

My two questions are:

(1) Is it appropriate for an RFC to specifying requirements relating to legal
issues and laws?  Note, I think that the guidance that is provides is really
helpful and should be included in the document, but I'm a bit concerned as to
whether a standards track RFC should be stating formal
requirements/constraints related to enforcing legal requirements rather that
providing non-normative guidance.

(2) Related to the first question, if the IESG believes believes that providing
such requirements is okay, a further question is whether using RFC 2119
language is appropriate, or whether this should use regular English?

An example from section 9:

The AS MUST ensure a
legal basis exists for the data transfer before any data is released
to a particular RS.  The way the legal basis is established might
vary among jurisdictions and MUST consider the legal entities
involved.

I can see your point.  I believe this language is here to make a very strong 
statement on the needed for operational policies that conform to the variety of 
privacy laws which often governs some of this data.

I'll let the authors/co-chairs comment.  To start the discussion, let me 
propose rough text that dilutes the legal mandate a bit but tries to keep the 
spirit of the intent.

NEW
The AS MUST conform to jurisdictional constraints for the data transfer before 
any data is released to a particular RS.  These constraints will vary by 
jurisdictions; and their details and determining which apply to this release to 
RSs is outside the scope of this document.

Regards,
Roman






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

Re: [OAUTH-WG] OAuth 2.0 Pushed Authorization Requests: Implementation Status

[Vladimir Dzhuvinov]

Supported by

 * the Connect2id server

 * the open source OAuth 2.0 / OIDC SDK, and also picked up by some
   downstream security frameworks and projects

   https://connect2id.com/blog/pushed-authorisation-request-in-oauth-sdk


Adoption of PAR seems to be progressing rather well, which I find 
positive and a testament to the PAR simplicity and ingenuity.


Vladimir


On 24/03/2021 21:53, Hannes Tschofenig wrote:


Hi all,

I am working on the shepherd writeup and I need information about the 
implementation status of this specification.


Can you share whether you are implementing, or planning to implement 
this specification? If there is open source, please drop a link to the 
mailing list. If you implement it in your product, please let us know 
as well.


This information helps the steering committee to judge the quality and 
maturity of the work.


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


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

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Vladimir Dzhuvinov]

RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud"
value or setting it to the AS, the ultimate consumer, appears valid here.

Vladimir

On 11/02/2021 23:47, Andrii Deinega wrote:
> Hi Vladimir,
>
> What would be a value in the aud claim for refresh tokens?
>
> Regards,
> Andrii
>
>
> On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Hi Warren,
>
> On 08/02/2021 17:59, Warren Parad wrote:
>> None of that justified explicitly stating that refresh token
>> introspection shouldn't be done. At best it suggests that we
>> should explicitly add language in the draft to directly encourage
>> it.
>
> Did you mean discourage?
>
>> But if an AS wants to support it, we shouldn't stop them, or
>> suggest that they can't do it.
>
> The current draft doesn't mention refresh tokens at all. Its
> subject is the introspection of access tokens by authenticated
> resource servers and returning the response as a signed JWT. The
> use of refresh tokens at the introspection endpoint, per RFC 7662,
> is not forbidden by the draft.
>
>
>>
>> Allowing refresh tokens to be introspected can also create a
>> conflict with the sec recommendation to rotate them
>>
>>
>> Not following, can you explain this further?
>
> I just double checked the rotation spec. Use that triggers
> rotation is clearly specified as "access token response", so there
> should actually be no issues with confusing introspection as use.
>
> 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2
>
> RFC 7662 also seems to imply that a public client with a refresh
> token should not normally be able to introspect it, because it
> can't authenticate to the AS.
>
>> https://tools.ietf.org/html/rfc7662#section-2.2
>>To prevent token scanning attacks, the endpoint MUST also require
>>some form of authorization to access this endpoint, such as client
>>authentication as described in OAuth 2.0 [RFC6749 
>> <https://tools.ietf.org/html/rfc6749>] or a separate
>>OAuth 2.0 access token such as the bearer token described in OAuth
>>2.0 Bearer Token Usage [RFC6750 
>> <https://tools.ietf.org/html/rfc6750>].  The methods of managing and
>>validating these authentication credentials are out of scope of this
>>specification.
>
> Vladimir
>
>
>>
>>  
>>
>> Warren Parad
>>
>> Founder, CTO
>>
>> Secure your user data and complete your authorization
>> architecture. Implement Authress <https://authress.io>.
>>
>>
>> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> At first it may appear that allowing refresh tokens at the
>> introspection endpoint may be a logical thing to do, but in
>> practice there are issues with that and from an OAuth 2.x
>> perspective it's not easy to justify.
>>
>> If the point is to let clients check what authorization they
>> have been given OAuth 2.0 already provides a std way to do
>> that - in the access token response - the "scope" parameter:
>>
>> https://tools.ietf.org/html/rfc6749#section-5.1
>>
>> RAR has a similar parameter:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1
>>
>> If the point is to find if a refresh token is still valid -
>> this can be found out by simply using it. Allowing refresh
>> tokens to be introspected can also create a conflict with the
>> sec recommendation to rotate them. So thus it may be a better
>> idea to not let clients assume too much about them.
>>
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2
>>
>> If the AS is going to expose refresh token data to a client
>> it will also have to make a careful judgement what data it
>> exposes.
>>
>> https://tools.ietf.org/html/rfc7662#section-2.2
>>
>> For instance "sub". OAuth 2.x in the relation between AS and
>> client actually has no concept or definition of subject /
>> end-user identifier. And this is done for a good reason,
>> because it's not a user authentication protoco

Re: [OAUTH-WG] Authorization Header Encoding

[Vladimir Dzhuvinov]

Hi Justin,

Thanks for alerting us on this development.

+1 for keeping the updated HTTP semantics unencumbered by the
Authorization header formatting in RFC 6750.

IMO revising the RFC 6750 to reflect that is too late now, as few people
will notice. So updating the Bearer header definition in OAuth 2.1 seems
like the most sensible move. I expect OAuth 2.0 implementers who
maintain their software to pick up the 2.1 spec, sooner or later.

Vladimir


On 12/02/2021 00:01, Justin Richer wrote:
> The HTTP Working Group opened an issue for discussion in relation to
> the updated HTTP semantics specification. The core of the issue is the
> format of the “Authorization” header, which of course gets used by the
> “Bearer” scheme defined in RFC6750.
>
> https://github.com/httpwg/http-core/issues/733
>
> As it turns out, Bearer defines a more limited character set than is
> allowed by core HTTP, and doesn’t follow the HTTP guidelines and
> definitions for the Authorization header. There were a few
> observations on the call:
>
>  - The Bearer spec was limited because OAuth tokens were also allowed
> in HTTP URLs and form parameters (and therefore had to have a more
> limited character set)
>  - In practice people don’t actually restrict the values they put into
> this field; pretty much any implementation is just going to
> concatenate whatever access token value they get to the magic word
> “Bearer” and send it
>  - It’s not likely (or in my opinion proper) for the HTTP spec to
> change to address the oddities of RFC6750 and decisions that were made
> many years ago
>
> So the question is, what do we do about it? We could do a revision of
> 6750 that reflects reality better, pretty much just changing the ABNF.
>
> Or, we could update the definition of the Bearer header in the
> upcoming OAuth 2.1 specification.
>
> Are there other options?
>
>  — Justin
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Vladimir Dzhuvinov]

Hi Warren,

On 08/02/2021 17:59, Warren Parad wrote:
> None of that justified explicitly stating that refresh token
> introspection shouldn't be done. At best it suggests that we should
> explicitly add language in the draft to directly encourage it.

Did you mean discourage?

> But if an AS wants to support it, we shouldn't stop them, or suggest
> that they can't do it.

The current draft doesn't mention refresh tokens at all. Its subject is
the introspection of access tokens by authenticated resource servers and
returning the response as a signed JWT. The use of refresh tokens at the
introspection endpoint, per RFC 7662, is not forbidden by the draft.


>
> Allowing refresh tokens to be introspected can also create a
> conflict with the sec recommendation to rotate them
>
>
> Not following, can you explain this further?

I just double checked the rotation spec. Use that triggers rotation is
clearly specified as "access token response", so there should actually
be no issues with confusing introspection as use.

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2

RFC 7662 also seems to imply that a public client with a refresh token
should not normally be able to introspect it, because it can't
authenticate to the AS.

> https://tools.ietf.org/html/rfc7662#section-2.2
>To prevent token scanning attacks, the endpoint MUST also require
>some form of authorization to access this endpoint, such as client
>authentication as described in OAuth 2.0 [RFC6749 
> <https://tools.ietf.org/html/rfc6749>] or a separate
>OAuth 2.0 access token such as the bearer token described in OAuth
>2.0 Bearer Token Usage [RFC6750 <https://tools.ietf.org/html/rfc6750>].  
> The methods of managing and
>validating these authentication credentials are out of scope of this
>specification.

Vladimir


>
>   
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://authress.io>.
>
>
> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> At first it may appear that allowing refresh tokens at the
> introspection endpoint may be a logical thing to do, but in
> practice there are issues with that and from an OAuth 2.x
> perspective it's not easy to justify.
>
> If the point is to let clients check what authorization they have
> been given OAuth 2.0 already provides a std way to do that - in
> the access token response - the "scope" parameter:
>
> https://tools.ietf.org/html/rfc6749#section-5.1
>
> RAR has a similar parameter:
>
> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1
>
> If the point is to find if a refresh token is still valid - this
> can be found out by simply using it. Allowing refresh tokens to be
> introspected can also create a conflict with the sec
> recommendation to rotate them. So thus it may be a better idea to
> not let clients assume too much about them.
>
> 
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2
>
> If the AS is going to expose refresh token data to a client it
> will also have to make a careful judgement what data it exposes.
>
> https://tools.ietf.org/html/rfc7662#section-2.2
>
> For instance "sub". OAuth 2.x in the relation between AS and
> client actually has no concept or definition of subject / end-user
> identifier. And this is done for a good reason, because it's not a
> user authentication protocol. OIDC was designed for that. And to
> prevent tracking of users and other privacy issues OIDC also
> specifies pairwise subject IDs. The plain OAuth 2.x world doesn't
> have this.
>
> Vladimir
>
> On 08/02/2021 11:07, Warren Parad wrote:
>> It doesn't work that way. You suggested to add language to the
>> draft, that means the burden of proof is on you to justify adding
>> it.
>>
>> Otherwise I could just say why not?
>>
>> And I can go stronger, what's the purpose of nho introspection
>> endpoint at all, and why encourage sending access tokens to the AS?
>>
>> Even if you can justify access tokens, there currently isn't
>> evidence provided why we should explicity discourage.
>>
>>
>> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt
>> mailto:tors...@lodderstedt.net>> wrote:
>>
>>
>>
>>> Am 08.02.2021 um 00:56 schrieb Warren Parad
>>> mailto:wpa...@rhosys.ch>>:
>>>
>>

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT)

[Vladimir Dzhuvinov]

der field" again.

Fixed.


>
>If possible, the AS MUST narrow down the "scope" value to the
>scopes relevant to the particular RS.
>
> What's the difference between "if possible,  MUST" and " SHOULD"?

Edited to

> The AS SHOULD narrow down the scope value to the scopes relevant to
> the particular RS.

>
>The JWT MAY include other claims, including those from the "JSON Web
>Token Claims" registry established by [RFC7519].  The JWT SHOULD NOT
>include the "sub" and "exp" claims as an additional prevention
>against misuse of the JWT as an access token (see Section 8.1).
>
> nit: I think a comma after "'exp' claims" would increase clarity.

Thanks, fixed.


>The JWT is cryptographically secured as specified in [RFC7662].
>
> I think that this was intended to refer to 7519 (JWT), not 7662
> (introspection)?

Thanks, the RFC ref was corrected.


>
>Depending on the specific resource server policy the JWT is either
>signed, or signed and encrypted.  If the JWT is signed and encrypted
>it MUST be a Nested JWT, as defined in JWT [RFC7519].
>
>Note: If the resource server policy requires a signed and encrypted
>
> (nit?) Just to confirm: the "resource server policy" here is a policy
> that's applied at the AS on a per-resource-server basis?  If so, perhaps
> writing it "resource-server-specific policy" would clarify.

Clarified as suggested.


>
>response and the authorization server receives an unauthenticated
>request containing an "Accept" header with content type other than
>"application/token-introspection+jwt", it MUST refuse to serve the
>request and return an HTTP status code 400.  This is done to prevent
>downgrading attacks to obtain token data intended for release to
>legitimate recipients only (see Section 8.2).
>
> An unauthenticated request should be denied unconditionally, right?
> Should this MUST apply to just requests containing the "Accept" header
> (field) with other content-types?

The section was rewritten to

> Note: If the AS requires signed introspection responses for some or
> all resource servers it MUST refuse to serve introspection requests
> that don't authenticate the caller and return an HTTP status code 400.
> This is done to prevent downgrading attacks to obtain token data
> intended for release to legitimate recipients only (see
> "token_data_leakage").

This greatly simplified things and allowed the security recommendations
section to be shortened significantly.



>
>The example response JWT payload contains the following JSON
>document:
>[...]
>  "token_introspection":
> {
>[...]
>"scope":"read write dolphin",
>
> Is there any chance the minimizer that was run on this payload as input
> to JWT generation also removed the spaces in the scope string?  I seem
> to be having some unexpected behavior from my local tooling, but it is
> looking like the claims set from the example HTTP payload lists
> "scope":"readwritedolphin".

I'm not sure what the issue here is, but we'll keep an eye on the
formatting of this example.


> Section 8.2
>
>To prevent introspection of leaked tokens and to present an
>additional security layer against token guessing attacks the
>authorization server MAY require all requests to the token
>introspection endpoint to be authenticated.  As an alternative or as
>an addition to the authentication, the intended recipients MAY be set
>up for encrypted responses.
>
> Isn't this ("require all requests to be authenticated") also a MUST now?

This section was removed entirely with the requirement to have all
requests authenticated.

The potential loophole of using a bearer access token for the
introspection endpoint where the authorised subject is not identified
(RFC 7662, section 2.2) is closed now.

https://tools.ietf.org/html/rfc7662#section-2.2


Vladimir

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797

[Vladimir Dzhuvinov]

Hi Andrii,

The unencoded payload JWS from RFC 7797 appears to be harder to get
right. Web frameworks can for instance make serialization and parsing of
JSON and text in general in HTTP unpredictable or difficult to control.
A single \n introduced at the end of the body can for instance break the
signature (been in one such situation). Incorrectly set charsets can
also cause issues. To mitigate this there has been an effort to
canonicalize JSON.

Also note that the JSON payload of the signed introspection response is
not a 1:1 copy of the RFC 7662 token introspection response. It includes
claims outside the token_introspection container - iss, aud and iat. So
where will they go and how is the signature going to include them as well?

There's also the issue with encryption - we don't have a standard way of
doing JWE over an RFC 7797 style signed text yet.

Vladimir

On 07/02/2021 11:56, Andrii Deinega wrote:
> Hi WG.
>
> draft-ietf-oauth-jwt-introspection-response-10 proposes to return
> signed JWTs as a response from the introspection endpoint... which is
> making me wonder if there are any particular reasons to not avail JSON
> Web Signature (JWS) Unencoded Payload Option (RFC 7797) and the
> X-JWS-SIGNATURE HTTP header in order to achieve the same goals?
>
> Pros would be
>
>  1. a token introspection response remains to be exactly the same as
> it was before with an exception for a JWT in the X-JWS-SIGNATURE
> HTTP header (where a detached payload is the actual token
> introspection response)
>  2. the AS can safely enable it for all responses from the
> introspection endpoint so clients who don't require or just aren't
> aware of this header will continue to work as before and
> accordingly, the clients who require some stronger assurance will
> require and check a JWT in X-JWS-SIGNATURE HTTP header
>  3. the same approach could also work for other endpoints such as the
> revocation and OIDC UserInfo endpoints
>
> What do you think?
>
> Regards,
> Andrii
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

[Vladimir Dzhuvinov]

ntrospection for checking the state of a token from
>> the client side has limited utility. The definitive decision
>> is always made when the client tries to access a resource. 
>>
>> I‘m therefore leaning towards explicitly stating in our draft
>> that it is not intended to be used with refresh tokens.
>>
>> best regards,
>> Torsten.
>>
>>>
>>> Regards,
>>> Andrii
>>>
>>>
>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt
>>> mailto:tors...@lodderstedt.net>>
>>> wrote:
>>>
>>> Hi Andrii,
>>>
>>> thanks for your post.
>>>
>>> The draft is intended to provide AS and RS with a
>>> solution to exchange signed (and optionally encrypted)
>>> token introspection responses in order to provide
>>> stronger assurance among those parties. This is
>>> important in use cases where the RS acts upon the
>>> introspection response data and wants the AS to take
>>> liability re the data quality.
>>>
>>> I’m not sure whether there are similar use cases if a
>>> client introspects a refresh token. What is your use case?
>>>
>>> best regards,
>>> Torsten. 
>>>
>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega
>>> >> <mailto:andrii.dein...@gmail.com>>:
>>> >
>>> > Hi WG,
>>> >
>>> > draft-ietf-oauth-jwt-introspection-response-10 states
>>> that "OAuth 2.0 Token Introspection [RFC7662] specifies
>>> a method for a protected resource to query an OAuth 2.0
>>> authorization server to determine the state of an access
>>> token and obtain data associated with the access token."
>>> which is true. Although, according to RFC7662, the
>>> introspection endpoint allows to introspect a refresh
>>> token as well. Hence, the question I have is how will a
>>> token introspection response look like when the caller
>>> provides a refresh token and sets the "Accept" HTTP
>>> header to "application/token-introspection+jwt"?
>>> >
>>> > I expect there will be no differences, right?
>>> >
>>> > If so, I suggest to
>>> >       • replace "a resource server" by "the caller" in
>>> section 4 (Requesting a JWT Response)
>>> >       • change "If the access token is invalid,
>>> expired, revoked" by "If a given token is invalid,
>>> expired, revoked" in section 5 (JWT Response)
>>> > If not, my suggestion would be to clarify what the AS
>>> should do when it asked to introspect the refresh token
>>> in general and additionally, what should happen in the
>>> same case based on the type of the caller from the AS's
>>> point of view.
>>> >
>>> > Regards,
>>> > Andrii
>>> >
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=161334699700=AOvVaw3ZHWt08dlcHAgxyfj2hrsX>
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Tenancy in OAuth

[Vladimir Dzhuvinov]

On 13/01/2021 12:10, Jaap Francke wrote:
> Thanks Justin and Vladimir for your guidance!
>
> The resource indicator approach seems to have the best fit for my use case.
> It addresses my coarse/mid-grained use case, without bringing the complexity 
> of the fine-grained RAR approach.
> Encoding the tenant into scope values remains an option as well.
> Ensuring the token validation is implemented properly is indeed a point of 
> attention.
>
> Meanwhile I've been looking into OAuth/OIDC specs for client registration. 
> It may also be useful to extend the client's metadata with 'resource' to bind 
> the specific client to a specific tenant(s).
> Would that make sense to you as well?

If that make sense in your scenario, then why not. We have the "scope"
client metadata field, which was intended for that purpose, but relating
to the scope authZ parameter.

https://tools.ietf.org/html/rfc7591#section-2

>scope
>   String containing a space-separated list of scope values (as
>   described in Section 3.3 
> <https://tools.ietf.org/html/rfc7591#section-3.3> of OAuth 2.0 [RFC6749 
> <https://tools.ietf.org/html/rfc6749>]) that the client
>   can use when requesting access tokens.  The semantics of values in
>   this list are service specific.  If omitted, an authorization
>   server MAY register a client with a default set of scopes.


Vladimir


>
> Great feedback, kind regards, 
> Jaap
>
>
> On 12/01/2021, 23:10, "OAuth on behalf of oauth-requ...@ietf.org" 
>  wrote:
>
> Send OAuth mailing list submissions to
>   oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauthdata=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3Dreserved=0
> or, via email, send a message with subject or body 'help' to
>   oauth-requ...@ietf.org
>
> You can reach the person managing the list at
>   oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Re: Tenancy in OAuth (Justin Richer)
>2. Re: Tenancy in OAuth (Vladimir Dzhuvinov)
>
>
> --
>
> Message: 1
> Date: Tue, 12 Jan 2021 16:13:26 -0500
> From: Justin Richer 
> To: Jaap Francke 
> Cc: "oauth@ietf.org" 
> Subject: Re: [OAUTH-WG] Tenancy in OAuth
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jaap,
>
> There have been a number of efforts to address this kind of thing in the 
> OAuth world. You can definitely use a special scope to encode this value, 
> which has the benefit of fitting into the implementation limitations of 
> nearly all OAuth systems out there. The ?resource? parameter can also be used 
> for the kind of thing, and it gives you a bucket that?s separate from ?scope? 
> so that you can keep the latter available for describing the API itself:
>
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3Dreserved=0
>  
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3Dreserved=0>
>
> There?s also the Rich Authorization Request (RAR) draft that this group 
> is currently working on, which provides a multi-dimensional way to describe 
> access. It?s more complex than scopes, but it boils down to having JSON 
> objects describe the elements needed. In this case you might put the API bits 
> into the ?actions? and ?datatypes? fields, and put the tenant information 
> into the ?locations? field. I believe there are people using it in exactly 
> this way today:
>
> 
> https://eur03.saf

Re: [OAUTH-WG] Tenancy in OAuth

[Vladimir Dzhuvinov]

Hello Jaap,

Justin made a good overview of the available OAuth facilities when
dealing with multiple resource servers or resource server tenants.

If you have control over the resource server, i.e. the token validation
is going to happen in one place, then you have plenty of freedom to find
out what will work best for you, semantically and in terms of available
OAuth server.

In cases when the resources are left to implement the token validation
on their own my preferred approach is to encode the resource server
identity (tenant) into the scope values. Access is defined in one place
and I don't have to worry about the developer accidentally forgetting
the "resource" or "aud(ience)" check.

Vladimir


On 12/01/2021 23:13, Justin Richer wrote:
> Hi Jaap,
>
> There have been a number of efforts to address this kind of thing in
> the OAuth world. You can definitely use a special scope to encode this
> value, which has the benefit of fitting into the implementation
> limitations of nearly all OAuth systems out there. The “resource”
> parameter can also be used for the kind of thing, and it gives you a
> bucket that’s separate from “scope” so that you can keep the latter
> available for describing the API itself:
>
> https://tools.ietf.org/html/rfc8707
>
> There’s also the Rich Authorization Request (RAR) draft that this
> group is currently working on, which provides a multi-dimensional way
> to describe access. It’s more complex than scopes, but it boils down
> to having JSON objects describe the elements needed. In this case you
> might put the API bits into the “actions” and “datatypes” fields, and
> put the tenant information into the “locations” field. I believe there
> are people using it in exactly this way today:
>
> https://tools.ietf.org/html/draft-ietf-oauth-rar-03
>
> There are also some historical efforts to address this, including an
> “audience” and a (completely separate) “aud" parameter, but AFAIK
> neither of these have been raised to standard or even to common
> practice, and so I wouldn’t recommend it. I currently have a project
> to migrate a system that’s currently using one of these onto RAR.
>
>  — Justin
>
>> On Jan 12, 2021, at 11:20 AM, Jaap Francke
>> > <mailto:Jaap.Francke=40mendix@dmarc.ietf.org>> wrote:
>>
>> Hi,
>>  
>> I’m looking into the topic of tenancy. A multi-tenant service can be
>> considered as an OAuth Resource Server managing resources of
>> different tenants.
>> An AS makes authorization decisions and communicates these using
>> scopes, so one way would be to ‘encode’ the tenant into the scope values.
>> Another line of thought is to somehow bind/restrict an acces-token to
>> a certain tenant, leaving the set of scopes being used more static.
>>  
>> My question is whether this has been a topic that has been addressed
>> in the OAuth working group? Any common practice or draft?
>> Thanks in advance for your replies.
>>  
>> Kind regards,
>> * *
>> *Jaap Francke*
>> Product Manager Identity
>> +31(0)641495324
>>
>> mendix.com <http://mendix.com/>
>>
>> ** <http://www.mendix.com/>
>> * *
>>  
>> ___
>> 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

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Vladimir Dzhuvinov]

Thank you Justin for this honest account of your experience with DPoP.

To at_hash or not is maybe not solved yet, but at least it's clear
there's little enthusiasm about the OIDC style at_hash :)

Vladimir

On 15/12/2020 18:40, Justin Richer wrote:
> I went and implemented this proposal of including a token hash in both
> an AS (java) and client (javascript) on a system that was already
> using DPoP and OpenID Connect. What I did there was just use the
> existing code we had on the AS-side to calculate the “at_hash” in the
> ID Token from OIDC, which I also used to verify on the token-accepting
> portions. I had to implement the function on the client side, but that
> was only a couple lines using a crypto library to do the heavy hash lift.
>
> The most annoying part is dealing with the hash variability in the
> OIDC method. As Brian points out, this isn’t particularly robust, and
> it depends on the wrapper being JOSE. That’s not a huge deal because
> DPoP uses JOSE for its wrapper, but it’s still extra code to deal with
> — to the point where I just hardcoded the hash algorithm in my test so
> that I didn’t have to put together the switch case over the algorithm. 
>
> So in at least my own experience, the addition is minimal on both
> client and server, and whatever we would decide for the hash algorithm
> would be simple enough to manage. I have a slight preference for just
> picking something like SHA256 and calling it a day (and defining other
> hashes in the future when SHA256 is broken), but that’s not a hill I
> care to die on.
>
>  — Justin
>
>> On Dec 14, 2020, at 4:27 PM, Brian Campbell
>> > <mailto:bcampbell=40pingidentity....@dmarc.ietf.org>> wrote:
>>
>>
>>
>> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> If the current DPoP has code complexity "X", the relative
>> additional complexity to include access token hashes doesn't seem
>> like very much. An app choosing DPoP means accepting the code
>> complexity that comes with dealing with keys, composing the
>> signing inputs for the proofs, signing, the necessary changes to
>> the token and RS requests. On the other hand, for some people
>> that additional access token hash may become the straw that
>> breaks the camel's back, causing them to quit their jobs
>> developing web apps and never look back :)
>>
>> Yeah, the relative additional complexity to include an access token
>> hash maybe isn't too much but it's also not not nothing. It's a
>> different kind of operation than the other things you listed (yes, I
>> know there's a hash as part of the signing but it's abstracted away
>> from the developer in most cases) and something that can be quite
>> difficult to troubleshoot when different parties arrive at different
>> hash values. Hence my lack of conviction on this one way or the other. 
>>  
>>
>>
>> Have you thought about letting deployments decide about the
>> access token hash? To say look, there is also the option to bind
>> an access token to the DPoP proof, the security benefits can be
>> such an such, and this is how it can be done.
>>
>> What I don't like about that proposal: 
>>
>>   * It will complicate the spec
>>
>>   * The current spec doesn't require implementers / deployments
>> to make any decisions, apart from adopt / not DPoP (okay,
>> also choose a JWS alg) - which is actually a great feature to
>> have
>>
>>
>> I also don't like it for basically the same reasons. I've definitely
>> aimed to keep it simple from that perspective of not having a lot of
>> optionality or switches. It is a nice feature to have, when possible. 
>>
>>  
>>
>> Vladimir
>>
>>
>> On 12/12/2020 01:58, Brian Campbell wrote:
>>> Any type of client could use DPoP and (presumably) benefit from
>>> sender-constrained access tokens. So yeah, adding complexity
>>> specifically for browser-based applications (that only mitigates
>>> one variation of the attacks possible with XSS anyway)  has
>>> 'cost' impact to those clients as well. And should be considered
>>> in the cost/benefit. Including the AT hash isn't terribly
>>> complicated but it's not trivial either. I'm honestly still
>>> unsure but am leaning towards it not being worth adding. 
>>>
>>> On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck
>>> >> <mailto:phili...@pragmaticwebsecurity.c

Re: [OAUTH-WG] PAR error for redirect URI?

[Vladimir Dzhuvinov]

Hi Brian,

I'd like to propose the sentence in bold to be inserted into the current
section 2.3 of PAR -04:

https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3

The authorization server returns an error response with the same format
as is specified for error responses from the token endpoint in
Section 5.2 of [RFC6749] using the appropriate error code from therein
or from Section 4.1.2.1 of [RFC6749]. *In those cases where Section
4.1.2.1 of [RFC6749] prohibits automatic redirection with an error back
to the requesting client and hence doesn’t define an error code, for
example when the request fails due to a missing, invalid, or mismatching
redirection URI, the “invalid_request” error code can be used as the
default error code.*

Hope with this we can close the case.

Vladimir

On 04/12/2020 18:08, Brian Campbell wrote:
>
>
> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> If people have articulated a need to have an invalid_redirect_uri
> error for the PAR endpoint, then let's register it properly.
> Rifaat says there's still time to do this.
>
>
> Following from the response I recently sent to Neil, I don't think a
> legitimate need has been articulated.
> https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY/
>  
>
> I'm also okay with using the general invalid_request code for
> this. In this case a sentence, next to the current example,
> spelling out what the PAR endpoint must do on a invalid redirect
> URI will help.
>
> I don't know that that's needed either. But do have some text to
> suggest that you think would be helpful?
>
>  
>
> Vladimir
>
> On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote:
>> Torsten, Filip,
>>
>> You can absolutely make this change, as we are still very early
>> in the process. 
>> So feel free to continue this effort and try to get WG agreement
>> on this, and update the document as needed. 
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Thursday, December 3, 2020, Filip Skokan > <mailto:panva...@gmail.com>> wrote:
>>
>> To be clear, I'm not advocating to skip the registration,
>> just wanted to mention a potential concern. If the process
>> allows it and it will not introduce more delay to
>> publication, I think we should go ahead and register the
>> error code.
>>
>> Best,
>> *Filip*
>>
>>
>> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt
>> mailto:tors...@lodderstedt.net>> wrote:
>>
>>
>>
>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan
>> mailto:panva...@gmail.com>>:
>> >
>> > There are several documents already mentioning
>> "invalid_redirect_uri" as an error code, specifically
>> RFC7519 and OpenID Connect Dynamic Client Registration
>> 1.0. But these don't register it in the IANA OAuth
>> Extensions Error Registry, presumably because they're
>> neither for the authorization or token endpoints.
>> >
>> > While I think it'd be great if we had this error code
>> registered, I also worry that its registration could
>> confuse implementers to think it's okay to return it from
>> the authorization endpoint.
>>
>> I understand your concern. On the other hand, registering
>> the error code is in my opinion the proper way forward.
>> The registration is scoped to a usage location, should be
>> pushed authorization endpoint then, and RFC6749 gives
>> clear guidance on how to treat errors related to the
>> redirect URI at the authorization endpoint.
>>
>> "If the request fails due to a missing, invalid, or
>> mismatching
>>    redirection URI, … authorization server ... MUST NOT
>> automatically redirect the user-agent to the
>>    invalid redirection URI."
>>
>> I think if an implementor ignores this, it will ignore
>> any advise.
>>
>> best regards,
>> Torsten.
>>
>> >
>> > Best,
>> > Filip
>> >
>> >
>> > On Thu, 3 Dec 2020 at 00:29, Brian Campbell
>> >

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Vladimir Dzhuvinov]

;
>>> Yes, in the cookie world this is known as “Session
>>> Riding”. Having the worker for token isolation would
>>> make it possible to enforce a coarse-grained policy on
>>> outgoing requests to prevent total abuse of the AT.
>>>
>>> My main concern here is the effort of doing DPoP in a
>>> browser versus the limited gains. It may also give a
>>> false sense of security. 
>>>
>>>
>>>
>>> With all this said, I believe that the AS can lock down
>>> its configuration to reduce these attack vectors. A few
>>> initial ideas:
>>>
>>> 1. Disable silent flows for SPAs using RT rotation
>>> 2. Use the sec-fetch headers to detect and reject
>>> non-silent iframe-based flows
>>>
>>> For example,  an OAuth 2.0 flow in an iframe in
>>> Brave/Chrome carries these headers:
>>> /
>>> sec-fetch-dest: iframe
>>> sec-fetch-mode: navigate
>>> sec-fetch-site: cross-site
>>> sec-fetch-user: ?1
>>> /
>>>
>>>
>>> Philippe
>>>
>>>
>>> /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./
>>
>>
>> /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./
>
>
>
>
>
> /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

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Vladimir Dzhuvinov]

he DOM APIs
> 2. Setup polling to read the URL (this will be possible for
> same-origin pages, not for cross-origin pages)
> 3. Create an authorization request such as
> 
> “//authorize?response_type=code_id=..._uri=https%3A%2F%example.com
> 
> <http://example.com>=..._challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk_challenge_method=S256/”
> 4. Load this URL in the iframe, and keep polling
> 5. Detect the redirect back to the application with the code in
> the URL, retrieve code, and use PKCE (+ DPoP if needed) to
> exchange it for tokens
>
> In step 5, the application is likely to also try to exchange the
> code. This will fail due to a mismatching PKCE verifier. While
> noisy, I don’t think it affects the scenario. 
>
>
>> IMO, the online attack scenario (i.e., proxying malicious
>> requests through the victim’s browser) is quite appealing to an
>> attacker, despite the apparent inconvenience:
>>
>>  - the victim’s browser may be inside a corporate firewall or
>> VPN, allowing the attacker to effectively bypass these restrictions
>>  - the attacker’s traffic is mixed in with the user’s own
>> requests, making them harder to distinguish or to block
>>
>> Overall, DPoP can only protect against XSS to the same level as
>> HttpOnly cookies. This is not nothing, but it means it only
>> prevents relatively naive attacks. Given the association of
>> public key signatures with strong authentication, people may have
>> overinflated expectations if DPoP is pitched as an XSS defence.
>
> Yes, in the cookie world this is known as “Session Riding”. Having
> the worker for token isolation would make it possible to enforce a
> coarse-grained policy on outgoing requests to prevent total abuse
> of the AT.
>
> My main concern here is the effort of doing DPoP in a browser
> versus the limited gains. It may also give a false sense of security. 
>
>
>
> With all this said, I believe that the AS can lock down its
> configuration to reduce these attack vectors. A few initial ideas:
>
> 1. Disable silent flows for SPAs using RT rotation
> 2. Use the sec-fetch headers to detect and reject non-silent
> iframe-based flows
>
> For example,  an OAuth 2.0 flow in an iframe in Brave/Chrome
> carries these headers:
> /
> sec-fetch-dest: iframe
> sec-fetch-mode: navigate
> sec-fetch-site: cross-site
> sec-fetch-user: ?1
> /
>
>
> Philippe
>
>
> /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

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

[Vladimir Dzhuvinov]

Support with both hands!

Vladimir

On 08/12/2020 14:50, Rifaat Shekh-Yusef wrote:
> All,
>
> This is a call for adoption for the following AS Issuer Identifier in
> Authorization Response as a WG document:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>
> Please, provide your feedback on the mailing list by Dec 22nd.
>
> Regards,
>  Rifaat & Hannes




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

Re: [OAUTH-WG] PAR error for redirect URI?

[Vladimir Dzhuvinov]

If people have articulated a need to have an invalid_redirect_uri error
for the PAR endpoint, then let's register it properly. Rifaat says
there's still time to do this.

I'm also okay with using the general invalid_request code for this. In
this case a sentence, next to the current example, spelling out what the
PAR endpoint must do on a invalid redirect URI will help.

Vladimir

On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote:
> Torsten, Filip,
>
> You can absolutely make this change, as we are still very early in the
> process. 
> So feel free to continue this effort and try to get WG agreement on
> this, and update the document as needed. 
>
> Regards,
>  Rifaat
>
>
> On Thursday, December 3, 2020, Filip Skokan  > wrote:
>
> To be clear, I'm not advocating to skip the registration, just
> wanted to mention a potential concern. If the process allows it
> and it will not introduce more delay to publication, I think we
> should go ahead and register the error code.
>
> Best,
> *Filip*
>
>
> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt
> mailto:tors...@lodderstedt.net>> wrote:
>
>
>
> > Am 03.12.2020 um 09:56 schrieb Filip Skokan
> mailto:panva...@gmail.com>>:
> >
> > There are several documents already mentioning
> "invalid_redirect_uri" as an error code, specifically RFC7519
> and OpenID Connect Dynamic Client Registration 1.0. But these
> don't register it in the IANA OAuth Extensions Error Registry,
> presumably because they're neither for the authorization or
> token endpoints.
> >
> > While I think it'd be great if we had this error code
> registered, I also worry that its registration could confuse
> implementers to think it's okay to return it from the
> authorization endpoint.
>
> I understand your concern. On the other hand, registering the
> error code is in my opinion the proper way forward. The
> registration is scoped to a usage location, should be pushed
> authorization endpoint then, and RFC6749 gives clear guidance
> on how to treat errors related to the redirect URI at the
> authorization endpoint.
>
> "If the request fails due to a missing, invalid, or mismatching
>    redirection URI, … authorization server ... MUST NOT
> automatically redirect the user-agent to the
>    invalid redirection URI."
>
> I think if an implementor ignores this, it will ignore any advise.
>
> best regards,
> Torsten.
>
> >
> > Best,
> > Filip
> >
> >
> > On Thu, 3 Dec 2020 at 00:29, Brian Campbell
>  > wrote:
> > During the course of a recent OIDF FAPI WG discussion (the
> FAPI profiles use PAR for authz requests) on this issue it was
> noted that there's no specific error code for problems with
> the redirect_uri (the example in
> 
> https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3
> 
> 
> even shows a general error code with mention of the
> redirect_uri not being valid in the error description). Some
> folks on that call thought it would be worthwhile to have a
> more specific error code for an invalid redirect_uri and I
> reluctantly took an action item to raise the issue here. At
> the time I'd forgotten that PAR had already passed WGLC. But
> it's been sitting idle while awaiting the shepherd writeup
> since mid September so it's maybe realistic to think the
> window for a small change is still open.
> >
> > Presumably nothing like an "invalid_redirect_uri" error code
> was defined in RFC 6749 because that class of errors could not
> be returned to the client via redirection. But the data flow
> in PAR would allow for a "invalid_redirect_uri" so it's not an
> unreasonable thing to do.
> >
> > As I write this message, however, I'm not personally
> convinced that it's worth making a change to PAR at this
> point. But I did say I'd bring the question up in the WG list
> and I'm just trying to be true to my word. So here it is.
> Please weigh in, if you have opinions on the matter.
> >
> >
> >
> > 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 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Vladimir Dzhuvinov]

Noting two unrelated comments that came up:

 1. The iss value in the example doesn't appear to be URL encoded:


https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-example-authorization-respo


 2. There was the question from a developer whether error responses
should also have the iss. I suggest the spec to be more explicit
that iss is added to both success and error responses, and even
include a second example, with an error response.

Vladimir

On 10/11/2020 22:25, Takahiko Kawasaki wrote:
> Hi Vladimir,
>
> Good point. Considering the similarity to JAR (JWT Secured
> Authorization Response), if we apply the same logic, our discussion
> will eventually reach "response parameters outside the response JWT
> are almost meaningless in the context of JARM". For interoperability
> and simplicity, it may be good to say "MUST NOT" as you suggested.
>
> Taka
>
> On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Re Case 1: When JARM is used:
>
> A colleague pointed me to the following statement in the JARMs
> spec, so I'd suggest to say the "iss" MUST NOT be included when
> JARM is used:
>
> 
> https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-response-mode
>
>> All response parameters defined for a given response type are
>> conveyed in a JWT
>
> Now, there isn't a proper normative keyword in this JARM spec
> sentence, so I guess some may interpret this as a strong check for
> no other query params, while others may not. Hence the MUST NOT to
> prevent potential unintended errors.
>
> What are your thoughts on this?
>
> Vladimir
>
> On 06/11/2020 23:34, Takahiko Kawasaki wrote:
>> I implemented the draft quickly and found no big hurdle for
>> authorization server implementations. The current snapshot of my
>> implementation does not add the `iss` parameter when JARM is
>> used. However, for interoperability, I feel that the spec should
>> describe expected behaviors when a JWT is included in an
>> authorization response. The following is an implementer's comment
>> for some cases.
>>
>> Case 1: When JARM is used
>>
>> An `iss` claim is included in the response JWT as one of
>> top-level entries together with response parameters. It is not so
>> unnatural to regard the `iss` claim as a response parameter.
>> Conclusion would be "When JARM is used, the `iss` parameter is
>> not necessary."
>>
>> Case 2: When an ID token is issued
>>
>> It is unnatural to regard the `iss` claim in an ID token as a
>> response parameter. However, because FAPI Part 2 has already been
>> using an ID token as detached signature for integrity protection,
>> it would be difficult to find a convincing reason to prohibit
>> using the `iss` claim in an ID token as a countermeasure to
>> mix-up attacks. Conclusion would be "When an ID token is issued,
>> the `iss` parameter is not necessary."
>>
>> Case 3: When an unencrypted JWT access token is issued
>>
>> It is technically possible to use the `iss` claim in an
>> unencrypted JWT access token as the `iss` parameter. However,
>> requiring the client to check the `iss` claim means "The access
>> token is no longer opaque to the client." Conclusion would be
>> "Even when an access token is issued and its format is JWT, the
>> `iss` parameter is necessary."
>>
>> BTW, I found that a certain system raises an error when an
>> unknown response parameter (that is, the `iss` parameter) is
>> included in error authorization responses. To ask the
>> administrator of the system to regard the `iss` parameter as a
>> known one, at least the spec draft needs to be adopted by the
>> community as a working draft. I hope that "call for adoption" for
>> the draft will be conducted soon.
>>
>> Best Regards,
>> Taka
>>
>> On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki
>> mailto:t...@authlete.com>> wrote:
>>
>> It sounds that the Security Considerations section or
>> somewhere appropriate should have a paragraph like below.
>>
>> When an authorization response includes a JWT whose `iss`
>> claim represents the issuer identifier of the authorization
>> server, the `iss` claim can be used as a substitute fo

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Vladimir Dzhuvinov]

hen
> authorization server details can be manually configured in the
> client, the client must verify that all issuer values are
> unique.” (Or at least something along those lines, I’m sure my
>     wording can be improved. But if the client is correctly
> implementing rfc8414 or OIDC discovery [and does not have any
> manually configured authorization servers] then there’s no
> requirement for any further checks that the issuer is unique.)
>
> Joseph
>
>
>> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> This can potentially occur. If JARM is used "iss" becomes
>> redundant. To me JARM is an "enhanced" iss.
>>
>> If both are included a sensible client should make sure the
>> iss and the JARM iss match.
>>
>> My suggestion is to not require iss when a JARM is present,
>> but in case both do occur to have the client check both.
>>
>> Vladimir
>>
>> On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>> Hi Karsten,
>>>
>>> The specification mentions JARM. Does this specification
>>> require the iss response parameter even when JARM is used?
>>> That is, should an authorization response look like below?
>>>
>>> HTTP/1.1 302 Found
>>> Location:
>>> https://client.example.com/cb?response={JWT}={ISSUER}
>>> <https://client.example.com/cb?response=%7BJWT%7D=%7BISSUER%7D>
>>>
>>> Or, can the iss response parameter be omitted when JARM is used?
>>>
>>> A small feedback for the 3rd paragraph in Section 4:
>>> s/identifes/identifies/
>>>
>>> Best Regards,
>>> Taka
>>>  
>>>
>>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
>>> mailto:vladi...@connect2id.com>>
>>> wrote:
>>>
>>> Thanks Karsten, looks good to me now, no further comments.
>>>
>>> Vladimir
>>>
>>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Daniel and I published a new version of the "iss"
>>>> response parameter draft to address the feedback from
>>>> the WG.
>>>>
>>>> Changes in -01:
>>>>
>>>>   * Incorporated first WG feedback
>>>>   * Clarifications for use with OIDC
>>>>   * Added note that clients supporting just one AS are
>>>> not vulnerable
>>>>   * Renamed metadata parameter
>>>>   * Various editorial changes
>>>>
>>>>
>>>> We would like to ask you for further feedback and
>>>> comments on the new draft version.
>>>>
>>>> Best regards,
>>>> Karsten
>>>>
>>>>  Forwarded Message 
>>>> Subject:   New Version Notification for
>>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>> Date:  Sun, 01 Nov 2020 23:31:42 -0800
>>>> From:  internet-dra...@ietf.org
>>>> <mailto:internet-dra...@ietf.org>
>>>> To:Karsten Meyer zu Selhausen
>>>> 
>>>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Karsten
>>>> zu Selhausen 
>>>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Daniel
>>>> Fett  <mailto:m...@danielfett.de>
>>>>
>>>>
>>>>
>>>>
>>>> A new version of I-D,
>>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>> has been successfully submitted by Karsten Meyer zu
>>>> Selhausen and posted to the
>>>> IETF repository.
>>>>
>>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>> Revision: 01
>>>> Title: OAuth 2.0 Authorization Server Issuer Identifier
>>>> in Authorization R

Re: [OAUTH-WG] The response from the Google authorization endpoint

[Vladimir Dzhuvinov]

I suspect those params are to signal the client if the user was
(re)authenticated, prompted for consent and the consented scope. But
being non-std and non-documented params it would be best to ignore them.

Vladimir

On 05/11/2020 15:47, Alex Kalp wrote:
> Hi Vladimir,
>
> Thanks for the reply. Would be great if you can share your insights on
> how those parameters are being used.
>
> I could not find any public docs explaining their usage, so thought
> they probably are being used by the Google applications by themselves.
>
> Thanks!
>
>
> On Wed, Nov 4, 2020 at 9:00 PM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Hi Alex,
>
> OAuth 2.0 doesn't forbid other params to be present in the
> response. If you find such - ignore them.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2
>
>> The client MUST ignore unrecognized response parameters.
> I have a theory why those 3 extra params (scope, authuser, prompt)
> are there, but I don't think it would matter in your case.
>
> Vladimir
>
> On 05/11/2020 02:23, Alex Kalp wrote:
>> Hi All,
>>
>> While trying out the OAuth 2.0 authorization code grant type with
>> Google, I got the following response to my registered redirect_uri.
>>
>> 
>> https://localhost:9000/app_uri?*state*=caf324471khs872&%20*code*=4/5wFzvDar86R-AJWCIE&%20*scope*=profile%20openid%20https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=0&%20*prompt*=consent
>>
>> As per the RFC6749 section 4.1.2, the authorization response from
>> the authorization endpoint only includes code and state.
>>
>> Appreciate if you can share any insights on why Google adds
>> scope, authuser and prompt parameters to the response, which are
>> not in the OAuth 2.0 RFC - and do we consider those additional
>> parameters as a violation of the RFC6749?
>>
>> Thanks!
>> -Alex
>>



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

Re: [OAUTH-WG] The response from the Google authorization endpoint

[Vladimir Dzhuvinov]

Hi Alex,

OAuth 2.0 doesn't forbid other params to be present in the response. If
you find such - ignore them.

https://tools.ietf.org/html/rfc6749#section-4.1.2

> The client MUST ignore unrecognized response parameters.
I have a theory why those 3 extra params (scope, authuser, prompt) are
there, but I don't think it would matter in your case.

Vladimir

On 05/11/2020 02:23, Alex Kalp wrote:
> Hi All,
>
> While trying out the OAuth 2.0 authorization code grant type with
> Google, I got the following response to my registered redirect_uri.
>
> https://localhost:9000/app_uri?*state*=caf324471khs872&%20*code*=4/5wFzvDar86R-AJWCIE&%20*scope*=profile%20openid%20https://www.googleapis.com/auth/userinfo.profile&%20*authuser*=0&%20*prompt*=consent
>
> As per the RFC6749 section 4.1.2, the authorization response from the
> authorization endpoint only includes code and state.
>
> Appreciate if you can share any insights on why Google adds scope,
> authuser and prompt parameters to the response, which are not in the
> OAuth 2.0 RFC - and do we consider those additional parameters as a
> violation of the RFC6749?
>
> Thanks!
> -Alex
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Vladimir Dzhuvinov]

This can potentially occur. If JARM is used "iss" becomes redundant. To
me JARM is an "enhanced" iss.

If both are included a sensible client should make sure the iss and the
JARM iss match.

My suggestion is to not require iss when a JARM is present, but in case
both do occur to have the client check both.

Vladimir

On 02/11/2020 22:34, Takahiko Kawasaki wrote:
> Hi Karsten,
>
> The specification mentions JARM. Does this specification require the
> iss response parameter even when JARM is used? That is, should an
> authorization response look like below?
>
> HTTP/1.1 302 Found
> Location: https://client.example.com/cb?response={JWT}={ISSUER}
>
> Or, can the iss response parameter be omitted when JARM is used?
>
> A small feedback for the 3rd paragraph in Section 4:
> s/identifes/identifies/
>
> Best Regards,
> Taka
>  
>
> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Thanks Karsten, looks good to me now, no further comments.
>
> Vladimir
>
> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>
>> Hi all,
>>
>> Daniel and I published a new version of the "iss" response
>> parameter draft to address the feedback from the WG.
>>
>> Changes in -01:
>>
>>   * Incorporated first WG feedback
>>   * Clarifications for use with OIDC
>>   * Added note that clients supporting just one AS are not vulnerable
>>   * Renamed metadata parameter
>>   * Various editorial changes
>>
>>
>> We would like to ask you for further feedback and comments on the
>> new draft version.
>>
>> Best regards,
>> Karsten
>>
>>  Forwarded Message 
>> Subject: New Version Notification for
>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> Date:Sun, 01 Nov 2020 23:31:42 -0800
>> From:internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
>> To:  Karsten Meyer zu Selhausen
>> 
>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Karsten zu
>> Selhausen 
>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Daniel Fett
>>  <mailto:m...@danielfett.de>
>>
>>
>>
>>
>> A new version of I-D,
>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> has been successfully submitted by Karsten Meyer zu Selhausen and
>> posted to the
>> IETF repository.
>>
>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>> Revision: 01
>> Title: OAuth 2.0 Authorization Server Issuer Identifier in
>> Authorization Response
>> Document date: 2020-11-01
>> Group: Individual Submission
>> Pages: 10
>> URL:
>> 
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>> Status:
>> 
>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>> Html:
>> 
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>> Htmlized:
>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
>> Diff:
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>
>> Abstract:
>> This document specifies a new parameter "iss" that is used to
>> explicitly include the issuer identifier of the authorization server
>> in the authorization response of an OAuth authorization flow. If
>> implemented correctly, the "iss" parameter serves as an effective
>> countermeasure to "mix-up attacks".
>>
>>
>>
>> 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 <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>> -- 
>> Karsten Meyer zu Selhausen
>> IT Security Consultant
>> Phone:   +49 (0)234 / 54456499
>> Web: https://hackmanit.de | IT Security Consulting, Penetration 
>> Testing, Security Training
>>
>> Does your OAuth or OpenID Connect implementation use PKCE to strengthen 
>> the security? Learn more about the procetion PKCE provides and its 
>> limitations in our new blog post:
>> 
>> https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>

Re: [OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Vladimir Dzhuvinov]

Thanks Karsten, looks good to me now, no further comments.

Vladimir

On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>
> Hi all,
>
> Daniel and I published a new version of the "iss" response parameter
> draft to address the feedback from the WG.
>
> Changes in -01:
>
>   * Incorporated first WG feedback
>   * Clarifications for use with OIDC
>   * Added note that clients supporting just one AS are not vulnerable
>   * Renamed metadata parameter
>   * Various editorial changes
>
>
> We would like to ask you for further feedback and comments on the new
> draft version.
>
> Best regards,
> Karsten
>
>  Forwarded Message 
> Subject:  New Version Notification for
> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> Date: Sun, 01 Nov 2020 23:31:42 -0800
> From: internet-dra...@ietf.org
> To:   Karsten Meyer zu Selhausen
> , Karsten zu Selhausen
> , Daniel Fett 
>
>
>
>
> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> has been successfully submitted by Karsten Meyer zu Selhausen and
> posted to the
> IETF repository.
>
> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
> Revision: 01
> Title: OAuth 2.0 Authorization Server Issuer Identifier in
> Authorization Response
> Document date: 2020-11-01
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
> Html:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
> Htmlized:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>
> Abstract:
> This document specifies a new parameter "iss" that is used to
> explicitly include the issuer identifier of the authorization server
> in the authorization response of an OAuth authorization flow. If
> implemented correctly, the "iss" parameter serves as an effective
> countermeasure to "mix-up attacks".
>
>
>
> 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
>
>
> -- 
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the 
> security? Learn more about the procetion PKCE provides and its limitations in 
> our new blog post:
> https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

Re: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

[Vladimir Dzhuvinov]

Hi Karsten,

Thanks for the write up. I would like to suggest the name
authorization_response_iss_parameter_supported, instead of
iss_parameter_supported. To make it explicit and unambiguous that it's
about the authZ response.

Vladimir

On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote:
>
> Hello WG,
>
> adding the issuer identifier to the authorization response as a
> countermeasure to mix-up attacks is well-known on this list and
> already part of the security BCP (see 4.4.2
> ).
> However, the "iss" parameter is currently not properly specified.
> Daniel and I wrote an ID to solve this issue.
>
> We would like to ask the working group to give us feedback on our
> first draft version:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00
>
> Abstract
>
>    This document specifies a new parameter "iss" that is used to
>    explicitly include the issuer identifier of the authorization server
>    in the authorization response of an OAuth authorization grant.  If
>    implemented correctly, the "iss" parameter serves as an effective
>    countermeasure to "mix-up" attacks.
>
>
> The need for a proper specification of the "iss" parameter was
> discussed in this thread:
> https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/
>
> Best regards,
> Karsten
>
>
> -- 
> Karsten Meyer zu Selhausen
> IT Security Consultant
> Phone:+49 (0)234 / 54456499
> Web:  https://hackmanit.de | IT Security Consulting, Penetration Testing, 
> Security Training
>
> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the 
> security? Learn more about the procetion PKCE provides and its limitations in 
> our new blog post:
> https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> Universitätsstraße 60 (Exzenterhaus)
> 44789 Bochum
>
> Registergericht: Amtsgericht Bochum, HRB 14896
> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. 
> Christian Mainka, Dr. Marcus Niemietz
>



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

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Vladimir Dzhuvinov]

Hi Taka,

Speaking of the OIDC Core 1.0 conformance tests, IMO those should not
change with the publication of JAR.

Speaking of the FAPI 1.0 tests, those already require all request
parameters to be JWT-secured, which makes the requests also JAR
compliant: all parameters are found in the JWT, with scope (as complete
scope or minimally required scope=openid), response_type, client_id and
redirect_uri also having a copy outside the JWT, as query parameters.
Thus the request is OIDC as well as JAR compliant.

If I had an RP I would always construct OIDC auth requests like that, to
make sure they comply with OIDC as well as the new JAR spec (and will
not have issues with servers which implement both specs but are not able
to "switch" behavior for some reason).

Vladimir

On 23/09/2020 14:58, Takahiko Kawasaki wrote:
> Hi Vladimir,
>
> Thank you for your reply. It sounds that your opinion is "`scope`
> request parameter must exist outside the request object even if JAR
> applies if the authorization request is an OIDC request". I'm on the
> fence on this topic and just wondered whether those who had wanted to
> remove `response_type` outside the request object (although doing it
> was a breaking change) would want to remove `scope` outside the
> request object too with the same motivation (although I don't remember
> well what was the motivation). JAR dares to drop `response_type`, so
> it would not be surprising to see that JAR dares to drop `scope`
> (including `openid`) too.
>
> OIDC Core 1.0 requires `response_type`, but JAR allows omission of the
> parameter if the parameter is included in the request object.
>
> If we applied the same logic, we would be able to state:
>
> OIDC Core 1.0 requires `scope` (including `openid`), but JAR allows
> omission of the parameter if the parameter is included in the request
> object.
>
> In terms of `response_type`, practically speaking, JAR has modified
> OIDC Core 1.0. Because JAR has already been allowed to go so far as
> that point, I would say it is difficult to find a convincing reason
> not to allow omission of `scope`.
>
> AFAIK, in the context of OIDC Core 1.0, parameters that are required
> to exist outside a request object even if they are included in the
> request object are `client_id`, `response_type` and `scope`. Because
> `client_id` is mandatory in JAR (it has become mandatory after
> long discussion), discussion for the parameter is not needed. Because
> the community has already reached consensus that `response_type` can
> be omitted, discussion for the parameter is not needed, either. What
> I've brought here is discussion for `scope`, hopefully the last
> parameter that is affected by JAR.
>
> Again, I'm on the fence on this topic. However, because logical
> conclusion (at least of mine) is that JAR should allow omission of
> `scope` (it also should be noted that JAR's basic rule prohibits
> referring to request parameters outside a request object), I want to
> see explicit consensus if `scope` (including `openid`) outside a
> request object is still required even after JAR is enabled.
>
> In short, my question is "Should `scope` be omitted?" I guess that the
> conclusion will affect the official conformance suite.
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Hi Taka,
>
> On 21/09/2020 20:12, Takahiko Kawasaki wrote:
>> If we allow JAR (JWT Secured Authorization Request) to relax the
>> requirement of `response_type` request parameter (outside a
>> request object) from mandatory to optional, should we relax the
>> following requirement of `scope` request parameter stated in OIDC
>> Core 1.0 Section 6.1, too?
>>
>> --
>> Even if a scope parameter is present in the Request Object value,
>> a scope parameter MUST always be passed using the OAuth 2.0
>> request syntax containing the openid scope value to indicate to
>> the underlying OAuth 2.0 logic that this is an OpenID Connect
>> request.
>> --
>>
>> Otherwise, an authorization request like
>> "client_id=...(_uri)=..." fails if the request object
>> represents an OIDC request. An authorization request has to look
>> like "client_id=...(_uri)=...=openid" (`scope`
>> including `openid` has to be given) even if the authorization
>> server conforms to JAR and allows omission of `response_type`
>> request parameter.
>
> The bottom of section 5 has normative text which allows a JAR
> compliant server to also comply with the

Re: [OAUTH-WG] New podcast on identity specifications

[Vladimir Dzhuvinov]

The mTLS vs DPoP was good in articulating how the two specs are alike,
how they differ and which particular type of app they are meant to serve.

I'm saying this as a person who is generally allergic to technical
podcasts :)

Maybe every RFC that comes out of this WG should have a podcast link at
the top, where the authors discuss it in simple, honest and non-speccy
terms, because that's often how people are best able to perceive the
spirit and subtleties of some technical or spec work.

Vladimir

On 21/09/2020 09:40, Vittorio Bertocci wrote:
>
> Dear all,
>
> This is an informal mail to inform you that there’s a new podcast
> , identityunlocked.com
> , dedicated to inform and explain new
> identity specs developments for developers.
>
> You can find a more detailed explanation of the podcast’s goals in
> https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/,
> but the TL;DR is that the spec themselves aren’t all that easy to read
> for the non-initiated, and a lot of useful info emerges during the
> discussions leading to the spec but rarely surface in a usable form to
> the people who don’t participate in discussions.
>
> The first episode
> ,
> featuring Brian Campbell discussing MTLS & DPoP, should give you an
> idea of what season 1 of the show will look like.
>
> The full list of the first run is available here
> .
> Of 6 episodes, 3 of them are about specifications coming out of this
> WG- and all guests are actively involved in the IETF.
>
> My main goals sharing this info here are
>
>   * *Letting you know that the podcast exists*, so that you can make
> use of it if you so choose (e.g. referring people to it if they
> need to better understand something covered in an episode)
>   * *Soliciting proposals for new episodes*: topics you believe are
> currently underserved, topics you are often asked about, topics
> you would like to be interviewed about on the show
>   * *Growing the show’s subscriber base*. I was able to get backing
> from my company to produce a podcast that has exactly ZERO product
> pitches and is purely about identity specs promotion, on the
> gamble that the topic does have an audience finding it useful. So
> far the reception has been great, and we need to keep it up if we
> want to have a season 2.  
>
>  
>
> I hope you’ll find the initiative useful!
>
> Cheers,
>
> V.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

Re: [OAUTH-WG] Shepherd writeup for the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens -- Information about Implementations

[Vladimir Dzhuvinov]

A conforming implementation and looking forward to the final spec :)

https://connect2id.com/products/server/docs/datasheet#access-token-encoding-jwt

On 17/09/2020 15:55, Hannes Tschofenig wrote:
> Hi Vittorio, Hi all,
>
> I am working on the shepherd writeup for  
> and you can find the latest version here:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-writeups/Writeup_OAuth_JWT-Profile-for-AccessTokens.txt
>
> I am in need for information about implementations that are conformant to 
> this specification. This information would be listed in this write-up, as 
> background information to the IESG.
>
> 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




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

Re: [OAUTH-WG] [JAR] scope parameter outside request object of OIDC request

[Vladimir Dzhuvinov]

Hi Taka,

On 21/09/2020 20:12, Takahiko Kawasaki wrote:
> If we allow JAR (JWT Secured Authorization Request) to relax the
> requirement of `response_type` request parameter (outside a request
> object) from mandatory to optional, should we relax the following
> requirement of `scope` request parameter stated in OIDC Core 1.0
> Section 6.1, too?
>
> --
> Even if a scope parameter is present in the Request Object value, a
> scope parameter MUST always be passed using the OAuth 2.0 request
> syntax containing the openid scope value to indicate to the underlying
> OAuth 2.0 logic that this is an OpenID Connect request.
> --
>
> Otherwise, an authorization request like
> "client_id=...(_uri)=..." fails if the request object
> represents an OIDC request. An authorization request has to look like
> "client_id=...(_uri)=...=openid" (`scope` including
> `openid` has to be given) even if the authorization server conforms to
> JAR and allows omission of `response_type` request parameter.

The bottom of section 5 has normative text which allows a JAR compliant
server to also comply with the OIDC spec with its own style of request /
request_uri parameter handling insofar as to not reject other query
params (such as scope, etc). The difference is that according to JAR
their values cannot be used or merged (as in OIDC). But what can be
reasonably done is to detect scope=openid as you say and then switch to
OIDC style request object behavior.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30#section-5

>The client MAY send the parameters included in the request object
>duplicated in the query parameters as well for the backward
>compatibility etc.  However, the authorization server supporting this
>specification MUST only use the parameters included in the request
>object.

The confusion between the two specs clears when it's seen that the
request objects in OIDC and JAR have different objectives.

In OIDC the objective is to enable securing of selected parameters.

In JAR the objective is to secure the entire authz request.


>
> I think that implementers want to know consensus on this because it
> affects implementations. Has this been discussed yet?
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.


Vladimir



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

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-jwsreq-26: (with COMMENT)

[Vladimir Dzhuvinov]

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

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] ECDH-1PU encryption algorithm

[Vladimir Dzhuvinov]

On 10/08/2020 11:28, Neil Madden wrote:
> Thanks Vladimir,
>
> Responses below
>
>> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov  wrote:
>>
>> Hi Neil,
>>
>> I definitely like the elegance of the proposed alg for JOSE, it provides
>> something that isn't currently available in the various classes of algs
>> made standard in JOSE.
>>
>> I also wanted to ask what's happening with AES SIV for JOSE, if there's
>> traction / feedback / support there as well?
>>
>> https://tools.ietf.org/html/draft-madden-jose-siv-mode-02
> Thanks for bringing this up. I’ve not received much feedback about this one, 
> and I haven’t been very good at pushing it. If there is interest then I’d 
> certainly be interested in bringing this forward too. 
>
> That draft might be a better fit for eg the COSE WG though, which could then 
> also register identifiers for JOSE. What do you think?

If the COSE is the "proper" WG to get the spec completed and the algs
registered, then let it be COSE. We can continue the conversation there.
I support both drafts.

>
>> Vladimir
>>
>>
>>>> On 05/08/2020 13:01, Neil Madden wrote:
>>> Hi all,
>>> You may remember me from such I-Ds
>>> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
>>> proposes adding a new encryption algorithm to JOSE. I’d like to
>>> reserve a bit of time to discuss it at one of the upcoming interim
>>> meetings.
>>> The basic idea is that in many cases in OAuth and OIDC you want to
>>> ensure both confidentiality and authenticity of some token - for
>>> example when transferring an ID token containing PII to the client
>>> through the front channel, or for access tokens intended to be handled
>>> by a specific RS without online token introspection (such as the JWT
>>> access token draft). If you have a shared secret key between the AS
>>> and the client/RS then you can use symmetric authenticated encryption
>>> (alg=dir or alg=A128KW etc). But if you need to use public key
>>> cryptography then currently you are limited to a nested
>>> signed-then-encrypted JOSE structure, which produces much larger token
>>> sizes.
>>> The draft adds a new “public key authenticated encryption” mode based
>>> on ECDH in the NIST standard “one-pass unified” model. The primary
>>> advantage for OAuth usage is that the tokens produced are more compact
>>> compared to signing+encryption (~30% smaller for typical access/ID
>>> token sizes in compact serialization). Performance-wise, it’s roughly
>>> equivalent. I know that size concerns are often a limiting factor in
>>> choosing whether to encrypt tokens, so this should help.
>>> In terms of implementation, it’s essentially just a few extra lines of
>>> code compared to an ECDH-ES implementation. (Some JOSE library APIs
>>> might need an adjustment to accommodate the extra private key needed
>>> for encryption/public key for decryption).
>>> I’ve received a few emails off-list from people interested in using it
>>> for non-OAuth use-cases such as secure messaging applications. I think
>>> these use-cases can be accommodated without significant changes, so I
>>> think the OAuth WG would be a good venue for advancing this.
>>> I’d be interested to hear thoughts and discussion on the list prior to
>>> any discussion at an interim meeting.
>>> — Neil

-- 
Vladimir Dzhuvinov




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

Re: [OAUTH-WG] ECDH-1PU encryption algorithm

[Vladimir Dzhuvinov]

Hi Neil,

I definitely like the elegance of the proposed alg for JOSE, it provides
something that isn't currently available in the various classes of algs
made standard in JOSE.

I also wanted to ask what's happening with AES SIV for JOSE, if there's
traction / feedback / support there as well?

https://tools.ietf.org/html/draft-madden-jose-siv-mode-02

Vladimir


On 05/08/2020 13:01, Neil Madden wrote:
> Hi all,
>
> You may remember me from such I-Ds
> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
> proposes adding a new encryption algorithm to JOSE. I’d like to
> reserve a bit of time to discuss it at one of the upcoming interim
> meetings.
>
> The basic idea is that in many cases in OAuth and OIDC you want to
> ensure both confidentiality and authenticity of some token - for
> example when transferring an ID token containing PII to the client
> through the front channel, or for access tokens intended to be handled
> by a specific RS without online token introspection (such as the JWT
> access token draft). If you have a shared secret key between the AS
> and the client/RS then you can use symmetric authenticated encryption
> (alg=dir or alg=A128KW etc). But if you need to use public key
> cryptography then currently you are limited to a nested
> signed-then-encrypted JOSE structure, which produces much larger token
> sizes.
>
> The draft adds a new “public key authenticated encryption” mode based
> on ECDH in the NIST standard “one-pass unified” model. The primary
> advantage for OAuth usage is that the tokens produced are more compact
> compared to signing+encryption (~30% smaller for typical access/ID
> token sizes in compact serialization). Performance-wise, it’s roughly
> equivalent. I know that size concerns are often a limiting factor in
> choosing whether to encrypt tokens, so this should help.
>
> In terms of implementation, it’s essentially just a few extra lines of
> code compared to an ECDH-ES implementation. (Some JOSE library APIs
> might need an adjustment to accommodate the extra private key needed
> for encryption/public key for decryption).
>
> I’ve received a few emails off-list from people interested in using it
> for non-OAuth use-cases such as secure messaging applications. I think
> these use-cases can be accommodated without significant changes, so I
> think the OAuth WG would be a good venue for advancing this.
>
> I’d be interested to hear thoughts and discussion on the list prior to
> any discussion at an interim meeting.
>
> — Neil




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

Re: [OAUTH-WG] Namespacing "type" in RAR

[Vladimir Dzhuvinov]

On 21/07/2020 18:43, Torsten Lodderstedt wrote:
>
>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov  
>> wrote:
>>
>>
>>
>> On 21/07/2020 17:47, Justin Richer wrote:
>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov  
>>>> wrote:
>>>>
>>>> On 18/07/2020 17:12, Justin Richer wrote:
>>>>> I think publishing supported “type” parameters isn’t a bad idea, and it 
>>>>> aligns with publishing supported scopes and claims in discovery.
>>>> If you are a developer, would you like to be able to find out if the 
>>>> authorization_details for a given "type" has a JSON schema and what it 
>>>> looks like?
>>>>
>>>>
>>>>
>>> I think that would be a nice thing for an AS/API to offer, but I don’t 
>>> think it should be expected or required here. That might be a good note in 
>>> the guidance, say that if you use a URI for your “type” field then it would 
>>> be nice if it resolved to something either human or machine readable. What 
>>> I don’t want is for us to require every AS to have to resolve these URIs in 
>>> order to process and understand them. That’s why I’m taking the position of 
>>> it being a string, and the URI can provide disambiguation in the way you’re 
>>> talking about below.
>> We've been thinking about giving developers the possibility to discover the 
>> authorization_details JSON schema (if one is supplied) for a given type via 
>> a separate AS metadata parameter. Not by making the type a dereferceable 
>> URL, which will overload things too much.
>>
>> authorization_details_json_schemas : {
>> "" : "",
>> "" : "",
>>...
>>
>> }
>> The rationale -- to minimise the number of potential support calls for 
>> providers arising from "Oh dear, why do I get this invalid_request now..." 
>> with complex RAR JSON objects.
> We could borrow the "$schema” element. 

Could you elaborate?

> However, I’m on the fence regarding introducing a separate parameter for the 
> schema simply because it also introduce a new error cause if type and schema 
> are inconsistent. 

Another idea was to still let the AS be configured with optional JSON
schemas for each type, and if the schema check of the
authorization_details fails, to include a meaningful message in the
invalid_request error_description and the schema URL in the error_uri.

The downside of that is the schema cannot be discovered or retrieved
upfront.

We really want to make it easy for developers to debug their requests
when facing complex RARs, on their own, without having to rely on a
support desk.

IMO the std invalid_request is ok for communicating the condition of an
authorization_details object failing the schema check (if the additional
error code was your concern).

Vladimir




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

Re: [OAUTH-WG] Namespacing "type" in RAR

[Vladimir Dzhuvinov]

On 21/07/2020 17:47, Justin Richer wrote:
>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> On 18/07/2020 17:12, Justin Richer wrote:
>>> I think publishing supported “type” parameters isn’t a bad idea, and it 
>>> aligns with publishing supported scopes and claims in discovery.
>>
>> If you are a developer, would you like to be able to find out if the
>> authorization_details for a given "type" has a JSON schema and what
>> it looks like?
>>
>>
> I think that would be a nice thing for an AS/API to offer, but I don’t
> think it should be expected or required here. That might be a good
> note in the guidance, say that if you use a URI for your “type” field
> then it would be nice if it resolved to something either human or
> machine readable. What I don’t want is for us to require every AS to
> have to resolve these URIs in order to process and understand them.
> That’s why I’m taking the position of it being a string, and the URI
> can provide disambiguation in the way you’re talking about below.

We've been thinking about giving developers the possibility to discover
the authorization_details JSON schema (if one is supplied) for a given
type via a separate AS metadata parameter. Not by making the type a
dereferceable URL, which will overload things too much.

authorization_details_json_schemas : {

    "" : "",

    "" : "",

   ...

}

The rationale -- to minimise the number of potential support calls for
providers arising from "Oh dear, why do I get this invalid_request
now..." with complex RAR JSON objects.


Vladimir




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

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

[Vladimir Dzhuvinov]

Thanks for the update. With the "require PAR" AS and client metadata the
spec is now "policy complete". I can't think of what else there is to add.


I have two comments about -02:


https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2

I didn't see a mention of https / TLS being required for the PAR
endpoint. The reader could assume http is fine.


https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2.2

>Since the request URI can be replayed, its lifetime SHOULD be short
>and preferably limited to one-time use.
The SHOULD is ambiguous here - does it apply to the lifetime only, or to
the lifetime and the single use.


Vladimir


On 10/07/2020 21:36, Brian Campbell wrote:
> WG,
>
> A new -02 draft of "OAuth 2.0 Pushed Authorization Requests" has been
> published. A summary of the changes, taken from the document history,
> is included below for ease of reference. 
>
>-02
>
>*  Update Resource Indicators reference to the somewhat recently
>   published RFC 8707 <https://datatracker.ietf.org/doc/html/rfc8707>
>
>*  Added metadata in support of pushed authorization requests only
>   feature
>
>*  Update to comply with draft-ietf-oauth-jwsreq-21 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21>, which 
> requires
>   "client_id" in the authorization request in addition to the
>   "request_uri"
>
>*  Clarified timing of request validation
>
>*  Add some guidance/options on the request URI structure
>
>*  Add the key used in the request object example so that a reader
>   could validate or recreate the request object signature
>
>*  Update to draft-ietf-oauth-jwsreq-25 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-25> and added 
> note regarding
>   "require_signed_request_object"
>
> -- Forwarded message -
> From: mailto:internet-dra...@ietf.org>>
> Date: Fri, Jul 10, 2020 at 1:21 PM
> Subject: New Version Notification for draft-ietf-oauth-par-02.txt
> To: Filip Skokan mailto:panva...@gmail.com>>,
> Torsten Lodderstedt  <mailto:tors...@lodderstedt.net>>, Brian Campbell
> mailto:bcampb...@pingidentity.com>>, Dave
> Tonge mailto:d...@tonge.org>>, Nat Sakimura
> mailto:n...@sakimura.org>>
>
>
>
> A new version of I-D, draft-ietf-oauth-par-02.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-ietf-oauth-par
> Revision:       02
> Title:          OAuth 2.0 Pushed Authorization Requests
> Document date:  2020-07-10
> Group:          oauth
> Pages:          18
> URL:           
> https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
> Htmlized:       https://tools..ietf.org/html/draft-ietf-oauth-par-02
> <https://tools.ietf.org/html/draft-ietf-oauth-par-02>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-02
>
> Abstract:
>    This document defines the pushed authorization request endpoint,
>    which allows clients to push the payload of an OAuth 2.0
>    authorization request to the authorization server via a direct
>    request and provides them with a request URI that is used as
>    reference to the data in a subsequent 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
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
> /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

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Namespacing "type" in RAR

[Vladimir Dzhuvinov]

On 18/07/2020 17:12, Justin Richer wrote:
> I think publishing supported “type” parameters isn’t a bad idea, and it 
> aligns with publishing supported scopes and claims in discovery.

If you are a developer, would you like to be able to find out if the
authorization_details for a given "type" has a JSON schema and what it
looks like?


> I have always seen the resource indicators work as providing a more specific 
> dimension to the requests that scopes didn’t allow to be described very well, 
> pointing at a specific RS instead of just “some kind of access”, so I’m not 
> sure how they’re a testament to name spacing issues with scopes. Can you help 
> me understand here?

Putting the scopes for each RS in a unique name space, for example by
giving them a URI prefix which identifies the RS, can make the resource
indication redundant.

RS: https://some-rs.example.com/

RS scopes: read, update, delete

->

https://some-rs.example.com/read

https://some-rs.example.com/update

https://some-rs.example.com/delete

This will not work if the chosen name spacing pattern can produce
ambiguities, e.g. if https://rs.example.com/accounts and
https://rs.example.com/accounts/v1 are two different RSes.


I have witnessed situations when an AS is given some application to deal
with, with hard-wired scope values that have no name spacing, and to
prevent potential collisions with other applications, Resource
Indicators had to come to the rescue.

I also remember one case with an application having a scope name which
is also used for the OIDC userinfo endpoint.


> I do think that if nothing else we can give better guidance in RAR as to what 
> the “type” field is. 

+1


> I do think it should still just be a string, but we can help people make 
> better decisions about what to put in that string.

I'm still on the fence with that but I do see your argument.


Vladimir


>
>  — Justin
>
>> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov  
>> wrote:
>>
>>
>> On 17/07/2020 17:38, Justin Richer wrote:
>>> And all that brings me to my proposal: 
>>>
>>> 4) Require all values to be defined by the AS, and encourage specification 
>>> developers to use URIs for collision resistance.
>>>
>>> So officially in RAR, the AS would decide what “type” means, and nobody 
>>> else. But we can also guide people who are developing general-purpose 
>>> interoperable APIs to use URIs for their RAR “type” definitions. This would 
>>> keep those interoperable APIs from stepping on each other, and from 
>>> stepping on any locally-defined special “type” structure. But at the end of 
>>> the day, the URI carries no more weight than just any other string, and the 
>>> AS decides what it means and how it applies.
>> Define, but not publish in AS metadata?
>>
>>
>>> My argument is that this seems to have worked very, very well for scopes, 
>>> and the RAR “type” is cut from similar descriptive cloth.
>> I would argue that it didn't work so well for scopes - the OAuth
>> Resource Indicators spec is a testament to that.
>>
>> But one could also argue that scopes were not defined along the lines of
>> your proposal for "type" in RAR. In fact, RFC 6749 has no mention of
>> collision resistance or name spacing for scope values.
>>
>>
>> Vladimir
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] Namespacing "type" in RAR

[Vladimir Dzhuvinov]

On 17/07/2020 17:38, Justin Richer wrote:
> And all that brings me to my proposal: 
>
> 4) Require all values to be defined by the AS, and encourage specification 
> developers to use URIs for collision resistance.
>
> So officially in RAR, the AS would decide what “type” means, and nobody else. 
> But we can also guide people who are developing general-purpose interoperable 
> APIs to use URIs for their RAR “type” definitions. This would keep those 
> interoperable APIs from stepping on each other, and from stepping on any 
> locally-defined special “type” structure. But at the end of the day, the URI 
> carries no more weight than just any other string, and the AS decides what it 
> means and how it applies.

Define, but not publish in AS metadata?


> My argument is that this seems to have worked very, very well for scopes, and 
> the RAR “type” is cut from similar descriptive cloth.

I would argue that it didn't work so well for scopes - the OAuth
Resource Indicators spec is a testament to that.

But one could also argue that scopes were not defined along the lines of
your proposal for "type" in RAR. In fact, RFC 6749 has no mention of
collision resistance or name spacing for scope values.


Vladimir




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

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

[Vladimir Dzhuvinov]

+1

Vladimir

On 15/07/2020 20:54, Dick Hardt wrote:
> +1
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef
> mailto:rifaat.s.i...@gmail.com>> wrote:
>
> All,
>
> This is a *call for adoption* for the following *OAuth 2.1*
> document as a WG document:
> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>
> Please, provide your feedback on the mailing list by *July 29th.*
>
> Regards,
>  Rifaat & Hannes
>



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Vladimir Dzhuvinov]

On 09/07/2020 19:06, Dave Tonge wrote:
>
> If a particular implementation wants to allow a two stage transaction,
> they can simply pass some reference to the first auth in the
> subsequent RAR auth flows, e.g.
>
> First flow, a user grants access with the simple scope of
> "make_payments", the access token issued at the end of the grant
> allows access to a resource server endpoints /payment-consents. The
> payload the client receives back when hitting that endpoint is {*id:
> "123"*, paymentsStarted:[], paymentsCompleted:[]}
> The second flow the client uses RAR with authorization_details
> containing this object:
>
>     {
>          "type": "payment_initiation",
>          "actions": [
>             "initiate",
>             "status",
>             "cancel"
>          ],
>          "locations": [
>             "https://example.com/payments;
>          ],
>          "instructedAmount": {
>             "currency": "EUR",
>             "amount": "123.50"
>          },
>          "creditorName": "Merchant123",
>          "creditorAccount": {
>             "iban": "DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured": "Ref Number Merchant",
>          *"paymentConsentId": "123",*
>       }
>
> This type of flows seems to better separate the AS and the RS
>
What I like about this proposal:

 1. It keeps the linking / referencing self-contained, i.e. within the
RAR authorization_details.

 2. It doesn't require anything else in terms of OAuth, such a new
top-level authz request parameter.

 3. Applications / deployments are free how to define the "linking" /
"context" between RARs.

 4. Does not complicate the RAR spec further (the normative bits).


Vladimir




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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Vladimir Dzhuvinov]

On 09/07/2020 11:07, Neil Madden wrote:
>
>>
>> An AS is always free to implement the 2 step solution that you
>> proposed and indeed it could be easier to implement with RAR in the
>> manner you described, but I don't think it should be the prescribed
>> approach.
>
> How can an AS implement this with RAR? This is my point - there is no
> mechanism at all in RAR to link a transaction to any kind of prior
> consent. It’s not about mandating such an approach, it’s about
> *supporting* it at all. Every transaction in RAR is a blank slate at
> the moment.

The ability to reference an existing grant is a general problem with OAuth.

The grant management draft has a "grant_id" parameter which can be used
to reference prior consent. I suppose to reference prior consent as
context only a new |grant_management_mode|may be needed.

https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md

We also have OAuth Incremental Authorization, which references a refresh
token:

https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04


Vladimir



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

Re: [OAUTH-WG] OAuth 2.1-03 - WG adoption?

[Vladimir Dzhuvinov]

I find 03 well structured, well written and it shows that a lot of
thought and work has gone into it.

If this is a formal call for adoption - I support it.


> - defined new client type - credentialed clients - a client that has
> credentials, but the AS has not confirmed the identity of the client.
> Confidential clients have had their identity confirmed by the AS. We
> talked about changing the names of confidential and public, but
> thought that would be confusing. This new definition cleans up the
> text substantially.

I understand why this new client type was introduced. For the reader who
is not familiar with the recent OAuth RFCs and drafts - I suspect this
can still be confusing. There will likely be questions -- Why does this
difference between confidential and credentialed matter? What is a
concrete example of a credentialed client?

Also, people will likely ask themselves - what does the confirmation of
a (credentialed) client's identity by the AS actually mean and do?
(section 2.1)


>Authorization servers SHOULD consider the level of confidence in a
>client's identity when deciding whether they allow such a client
>access to more critical functions, such as the Client Credentials
>grant type.

Again, normative text that relies on the implementer being able to
assign levels of confidence in the client's identity, but is not
immediately obvious how to go about this.


There is mention in 9.1 about "enlisting the resource owner to confirm
identity" and "if there is a web application whose developer's identity
was verified...". But this talk about client identity is secondary and
happens in the context of client authentication.

Perhaps it will make sense to promote the discussion about identity to a
new 9.x section "Client identity" or "Client Identification", before
"Client Authentication". Addressing the topics what client identity is,
why does it matter (especially for security), and the "confirmation by
the AS". Then proceed with "Client Authentication" which now is freed to
focus on the credentials / auth methods aspects.

>Such credentials are either issued by the
>authorization server or registered by the developer of the client
>with the authorization server.

Credentials (public key) can also be registered by a client performing
dynamic registration (section 2.1)


Vladimir



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

Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Vladimir Dzhuvinov]

On 06/07/2020 19:32, Neil Madden wrote:
> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have
> some time, and I have a few comments.
>
> An assumption in the draft appears to be that the client knows ahead
> of time what it wants to gain access to and can describe it in detail.
> For example, the last example in section 2.1 is a client requesting
> access to particular files, which assumes that the client already
> knows the paths of the files it wants to access. This in turn seems to
> imply that the client already has some level of access to be able to
> determine this, e.g. to list directories, which may not be desirable.
> In many cases like this I think it’s more natural for the client to
> not know exactly what it is asking for but instead to want access to
> *some* file, chosen by the user. An example of this is the Dropbox
> Chooser [1] and Saver [2] APIs, which notably are not built on top of
> OAuth. In these cases it would be more natural for the client to send
> a more generic request and for the details to be filled in by the user
> as part of the consent process.
>
> Another issue is that as far as I can see in the current draft, any
> client can initiate a rich authorization request at any time without
> any kind of prior approval. This seems problematic for the main
> example in the draft, i.e. payment initiation. As an attacker, if I
> can get a consent screen up on a user’s device requesting to move
> money around then it seems like half my job is already done - some
> fraction of users will probably approve such a transaction without
> properly checking it. It feels like the ability to ask for transaction
> approval should already be a privileged operation that should require
> consent and approval.
>
> A related issue is that each approval is in effect a completely
> isolated incident. In a normal OAuth2 interaction I would grant an app
> some longish-term access to data and it would get an access token and
> optionally a refresh token. At some later point I can go to the AS and
> see that I have granted this access and revoke it if I choose. With
> RAR there is no representation of a long-term relationship between the
> RO and the client and each transaction starts from fresh. Again, this
> seems potentially problematic and not quite in keeping with how OAuth
> currently operates. Each grant of access is ephemeral. (Do refresh
> tokens make sense in the context of RAR?)

The original motivation for RAR was indeed transactions, which require
parameters, and this class of use cases do typically imply "ephemeral"
access (single-use token).

But nothing precludes RAR from being used for long term access (with a
refresh token) and there are one or two simple examples in the spec
which can be interpreted as such.

>
> I think a better approach would be a two-phase authorization process:
>
> 1. In step 1 an app gets a normal long-lived access and/or refresh
> token that grants it permissions to ask to initial transactions (RARs)
> - e.g. with scope initiate_payments
> 2. In step 2 the app requests authorization for individual
> RARs/transactions using some proof of its grant from step 1

Such a two-phase authorisation can make good sense in cases when user
trust needs to be built up.

Mentioning this and / or some other pattern can be useful, but I don't
think we should make this normative for RAR, because there can well be
use cases which won't need this.

>
> I have ideas for how this could be achieved, but I’d prefer to see
> what others think of this general idea rather than getting bogged down
> in specific details.
>
> [1]: https://www.dropbox.com/developers/chooser
> [2]: https://www.dropbox.com/developers/saver 
>
> — Neil




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

Re: [OAUTH-WG] Product Support for RFC8414 well-known URIs

[Vladimir Dzhuvinov]

On 08/06/2020 12:15, Daniel Fett wrote:
> That would be the safe implementation, but I was wondering if
> prescribing this is a good choice for an ecosystem.

Postfix vs infix:

If we reason about the common ways ASes (as web apps) get deployed, then
(perhaps) it will become obvious which method is the most natural and
likely to be taken.

  * For an AS which gets deployed in a dedicated host, e.g. as
as.example.com , the app root is likely to be
https://as.example.com/ and hence the config URL becoming a simple
postfix.

  * Multi-tenant ASes where each AS has a dedicated domain for each
issuer also.

  * For an AS which gets deployed as part of some larger app (e.g. as
module or package) on the same host, the AS is likely to end up at
some path like https://example.com/as/ and hence the config being
easier for a postfix URL.

  * Multi-tenant ASes which share a domain - this is not clear, but I
suppose both postfix and infix can be made to work without the one
method demanding more effort.


The infix is not natural, IMO, given the way apps get deployed. Postfix
seems more natural.

I may be wrong about these assumptions. But that's one good way to
approach the problem and specify something which implementers actually
find easier / natural. This, to me, is what an "ideal" technical
standard is.

Vladimir




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

Re: [OAUTH-WG] Downgrade attacks on PKCE

[Vladimir Dzhuvinov]

Thanks for laying out the solutions so neatly.

We would prefer #2 the "dynamic" solution because it wouldn't require us
to do any changes. I've had the impression that the unexpected
code_verifier case was somehow covered as an error in RFC 7636 but
checked the spec now and apparently it isn't.

Vladimir

On 30/05/2020 10:58, Daniel Fett wrote:
> Hi all,
>
> Aaron, Dick, Torsten and I today discussed the downgrade attacks on
> PKCE [1] and how to mitigate them in OAuth 2.1 and 2.0. We came to the
> conclusion that we have two options:
>
> *1. "Static" Solution*
>
> For every client_id that is registered with an AS, the AS MUST either
> always enforce the use of PKCE or always enforce the use of nonce.
> Whether PKCE or nonce is enforced can be part of the client
> registration or configured in other ways.
>
> In other words: A single client is not allowed to switch between using
> PKCE and using nonce.
>
> Note that the client is allowed to use the respective other mechanism
> on top of the enforced one.
>
> Properties:
>
>   * Easy to understand mitigation.
>   * Implementation is mainly a new data field and a check in the
> authorization request.
>   * Not compatible to deployments where clients sometimes use nonce
> and sometimes use PKCE with the same client_id. *
> ***
>
> **
>
> *2. "Dynamic" Solution*
>
> Each AS that supports PKCE MUST check whether a code challenge is
> contained in the authorization request. This information MUST be bound
> to the code that is issued.
>
> When a code arrives at the token endpoint, the AS MUST do the
> following check:
>
>  1. If there was a code_challenge in the authorization request for
> which this code was issued, there must be a code_verifier in the
> token request and it must be verified according to RFC7636. (This
> is no change from the current behavior in RFC7636.)
>  2. If there was no code_challenge in the authorization request, any
> request to the token endpoint containing a code_verifier MUST be
> rejected.
>
> Properties:
>
>   * No change in behavior needed for properly implemented clients.
> Backwards compatible for all existing deployments.
>   * Implementation is mainly some logic for the authorization
> endpoint, token endpoint, and a new data field in the
> authorization session maintained by the AS.
>   * Slightly more complex to implement for the AS, maybe.
>
> We would like to hear the feedback from the working group on these two
> solutions before proceeding to propose wording for the affected documents.
>
> [1] https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>
> -Daniel



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

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

[Vladimir Dzhuvinov]

With that said it makes sense to devise a structure which can
accommodate UI driven as well as automatic choice.

  * The UI driven chooser will need a human readable description and
other UI hints. This can work for instance with "classic" OIDC
Discovery.

  * The "auto" chooser will need some sort of an ID. For a bank chooser
this means providing the issuer URI and an optional brand ID and
both must get registered together. Or, one could define a standard
brand ID (label) for banking operations and if the
"alternative_authorization_endpoints" is present look for it in the
structure, else fall back to the default "authorization_endpoint".

Here is one possible layout which has IDs and UI hints:

{
  ...
  "alternative_authorization_endpoints": {
"banking": {
  "authorization_endpoint": "https://loadsamoney/business/auth;,
  "description": "loadsmoney business banking customers",
  "logo_url": "https://loadsamoney/business/logo.png;
},
"personal": {
  "authorization_endpoint": "https://loadsamoney/consumer/auth;,
  "description": "loadsmoney personal customers",
  "logo_url": "https://loadsamoney/consumer/logo.png;
}
  }
}


On 22/05/2020 09:59, Torsten Lodderstedt wrote:
> I think an id or label per endpoint set would be needed to determine the set 
> of endpoints to be used by a certain client.
>
> On the conceptual side, I’m asking myself how the complete process is 
> supposed to work. Who is deciding what issuer/endpoint set combination to 
> use. I assume in an open banking scenario, there will always be some kind of 
> bank chooser. Will this chooser provide the client with issuer and brand id? 
>
>> On 22. May 2020, at 08:10, Vladimir Dzhuvinov  
>> wrote:
>>
>> A mapping like the one you propose can definitely work. Since the user will 
>> be making the choice which endpoint to take with the client app, having the 
>> logo_uri is a good idea. If the branded endpoints differ somehow in policy 
>> one could also allow inclusion of the op_policy_uri and op_tos_uri params 
>> from Discovery.
>>
>> https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery
>>
>> Vladimir
>>
>> On 20/05/2020 19:16, Joseph Heenan wrote:
>>> Thanks for your thoughts Vladimir!
>>>
>>> The client_id based solution I wasn’t previously aware of - unfortunately 
>>> it doesn’t solve the problem for app2app, as the mobile OS selects the app 
>>> to use based purely on the URL (and in at least the iOS case will not offer 
>>> the user a choice if multiple apps claim to handle the same url).
>>>
>>> I think some kind of mapping like you suggest will work and fallback, I 
>>> wonder about a structure in the authorization server metadata something 
>>> like this:
>>>
>>> {
>>>   ...
>>>   "alternative_authorization_endpoints": [
>>> {
>>>   "authorization_endpoint": "https://loadsamoney/business/auth;,
>>>   "description": "loadsmoney business banking customers",
>>>   "logo_url": "https://loadsamoney/business/logo.png;
>>> },
>>> {
>>>   "authorization_endpoint": "https://loadsamoney/consumer/auth;,
>>>   "description": "loadsmoney personal customers",
>>>   "logo_url": "https://loadsamoney/consumer/logo.png;
>>> }
>>>   ]
>>> }
>>>
>>> And as you say, the existing authorization_endpoint can be a fallback for 
>>> clients that are unaware of the new spec or prefer the simpler option of 
>>> just using a single authorization endpoint. Supporting the new spec would 
>>> allow a better UX though so there’s advantages to client to do so.
>>>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be 
>>>> sensibly combined with the proposed multi-brand spec.
>>>>
>>> I think that particular part is not really an issue as mtls isn’t used at 
>>> the authorization endpoint.
>>>
>>> Thanks
>>>
>>> Joseph
>>>
>>>
>>>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov  
>>>> wrote:
>>>>
>>>> Hi Dave,
>>>>
>>>> In the absence of such a "multi-brand" spec we have tackled this issue in 
>>>> the past by letting the "brand" be encoded 

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

[Vladimir Dzhuvinov]

A mapping like the one you propose can definitely work. Since the user
will be making the choice which endpoint to take with the client app,
having the logo_uri is a good idea. If the branded endpoints differ
somehow in policy one could also allow inclusion of the op_policy_uri
and op_tos_uri params from Discovery.

https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

Vladimir

On 20/05/2020 19:16, Joseph Heenan wrote:
> Thanks for your thoughts Vladimir!
>
> The client_id based solution I wasn’t previously aware of -
> unfortunately it doesn’t solve the problem for app2app, as the mobile
> OS selects the app to use based purely on the URL (and in at least the
> iOS case will not offer the user a choice if multiple apps claim to
> handle the same url).
>
> I think some kind of mapping like you suggest will work and fallback,
> I wonder about a structure in the authorization server metadata
> something like this:
>
> {
>   ...
>   "alternative_authorization_endpoints": [
>     {
>       "authorization_endpoint": "https://loadsamoney/business/auth;,
>       "description": "loadsmoney business banking customers",
>       "logo_url": "https://loadsamoney/business/logo.png;
>     },
>     {
>       "authorization_endpoint": "https://loadsamoney/consumer/auth;,
>       "description": "loadsmoney personal customers",
>       "logo_url": "https://loadsamoney/consumer/logo.png;
>     }
>   ]
> }
>
> And as you say, the existing authorization_endpoint can be a fallback
> for clients that are unaware of the new spec or prefer the simpler
> option of just using a single authorization endpoint. Supporting the
> new spec would allow a better UX though so there’s advantages to
> client to do so.
>>
>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
>> sensibly combined with the proposed multi-brand spec.
>>
> I think that particular part is not really an issue as mtls isn’t used
> at the authorization endpoint.
>
> Thanks
>
> Joseph
>
>
>> On 20 May 2020, at 16:07, Vladimir Dzhuvinov > <mailto:vladi...@connect2id.com>> wrote:
>>
>> Hi Dave,
>>
>> In the absence of such a "multi-brand" spec we have tackled this
>> issue in the past by letting the "brand" be encoded in the client_id.
>> An alternative scenario is to do a "brand" lookup by client_id. Then
>> let the AS render the "branded" authZ endpoint.
>>
>> You're probably aware the mTLS spec is allowing for endpoint aliases,
>> so this is not the first time such as need has occurred:
>>
>> https://tools.ietf.org/html/rfc8705#section-5
>>
>> One could devise a similar JSON object with mappings "label" -
>> "authorization_endpoint".
>>
>> Clients that are aware of the new spec will look it up, those that
>> are not will fall back to the std "authorization_endpoint".
>>
>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
>> sensibly combined with the proposed multi-brand spec.
>>
>>
>> Vladimir
>>
>>
>> On 20/05/2020 15:07, Dave Tonge wrote:
>>> Dear OAuth WG
>>>
>>> We have an issue
>>> <https://bitbucket.org/openid/fapi/issues/255/certification-clarification-request>
>>> in the OpenID FAPI Working Group that we believe affects the wider
>>> OAuth community.
>>>
>>> In summary: *what is the recommended approach to discovery (RFC8414)
>>> for Authorization Servers who support multiple "brands" .*
>>>
>>> If brands are completely separate, then it seems sensible that each
>>> brand must have its own `issuer` and therefore its own discovery
>>> document at the correct location (i.e. brand 1 would have an issuer
>>> of "https://as/brand1; and a discovery document available at 
>>> https://as/.well-known/oauth-authorization-server/brand1).
>>>
>>> However in the real world it is not always so simple. We have many
>>> existing implementations in UK open banking that support multiple
>>> authorization endpoints. Here is an example (thanks to @Joseph
>>> Heenan <mailto:joseph.hee...@fintechlabs.io> )
>>>
>>> > Bank “loadsamoney” has one idp and, for internet banking, one
>>> “login page” for both business and personal customers.
>>>
>>> > They have separate mobile apps for business/personal, and are
>>> required to support

Re: [OAUTH-WG] Issuers, Discovery Docs & Brands

[Vladimir Dzhuvinov]

Hi Dave,

In the absence of such a "multi-brand" spec we have tackled this issue
in the past by letting the "brand" be encoded in the client_id. An
alternative scenario is to do a "brand" lookup by client_id. Then let
the AS render the "branded" authZ endpoint.

You're probably aware the mTLS spec is allowing for endpoint aliases, so
this is not the first time such as need has occurred:

https://tools.ietf.org/html/rfc8705#section-5

One could devise a similar JSON object with mappings "label" -
"authorization_endpoint".

Clients that are aware of the new spec will look it up, those that are
not will fall back to the std "authorization_endpoint".

Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
sensibly combined with the proposed multi-brand spec.


Vladimir


On 20/05/2020 15:07, Dave Tonge wrote:
> Dear OAuth WG
>
> We have an issue
> 
> in the OpenID FAPI Working Group that we believe affects the wider
> OAuth community.
>
> In summary: *what is the recommended approach to discovery (RFC8414)
> for Authorization Servers who support multiple "brands" .*
>
> If brands are completely separate, then it seems sensible that each
> brand must have its own `issuer` and therefore its own discovery
> document at the correct location (i.e. brand 1 would have an issuer of
> "https://as/brand1; and a discovery document available at 
> https://as/.well-known/oauth-authorization-server/brand1).
>
> However in the real world it is not always so simple. We have many
> existing implementations in UK open banking that support multiple
> authorization endpoints. Here is an example (thanks to @Joseph Heenan
>  )
>
> > Bank “loadsamoney” has one idp and, for internet banking, one “login
> page” for both business and personal customers.
>
> > They have separate mobile apps for business/personal, and are
> required to support app2app. This means they will definitely be
> exposing multiple authorization endpoints (as there’s a 1:1 mapping of
> authorization endpoints to mobile apps) - the choice is how they do this.
>
> > Their choices are:
>
> > 1. Multiple discovery endpoints (one for business, one for
> personal), each with a different authorization endpoint, multiple
> issuers (if their vendor allows this)
> > 2. Single discovery endpoint, single issuer, multiple authorization
> endpoints listed in one discovery doc (one for business, one for
> personal) some of which are hardcoded by the 3rd party
> > 3. Multiple discovery endpoints each with a different authorization
> endpoint, same issuer in all cases (breaks RFC8414 and OIDC Discovery)
>
> Option 3 is invalid and that leaves us with options 1 and 2. 
> Option 1 can be problematic as often it is in reality the same
> `issuer` behind the scenes.
>
> We would like to get feedback on this issue and potentially an
> extension to RFC8414 to allow the definition of multiple authorization
> endpoints.
>
> Thanks in advance
>
> Dave Tonge
> Co-Chair FAPI WG
> Open ID Foundation
>
>



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

Re: [OAUTH-WG] PAR - Can AS/client require request object?

[Vladimir Dzhuvinov]

+1 for require_request_objects AS metadata parameter.

The natural place for this parameter for me would be the JAR spec .

Vladimir

On 12/05/2020 09:27, Torsten Lodderstedt wrote:
> Hi all,
>
> I initially raised the question whether the AS should be able to require 
> request objects for all clients (in the same way as we decided to let the AS 
> required PAR for all clients) but this topic was never discussed later on. 
>
> I suggest to add a server metadata parameter “require_request_objects” so the 
> AS can indicate its policy to clients. 
>
> I think the best place to define this parameter would be JAR, if that is not 
> possible any longer, we could use a different PAR-specific name and add it to 
> PAR.
>
> What do you think?
>
> best regards,
> Torsten. 
>
>> On 1. May 2020, at 17:56, Mike Jones 
>>  wrote:
>>
>> Works for me.
>>
>>  
>>
>> From: OAuth  On Behalf Of Torsten Lodderstedt
>> Sent: Friday, May 1, 2020 2:51 AM
>> To: Brian Campbell 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] PAR - Can AS/client require request object?
>>
>>  
>>
>> Filip´s proposal works for me.
>>
>>  
>>
>> Are there any objections?
>>
>>  
>>
>> Brian Campbell  schrieb am Mo. 
>> 27. Apr. 2020 um 20:57:
>>
>> While there are certainly different permutations and contexts of use that 
>> could be imagine, I tend to agree with Filip here in not seeing a strong 
>> need to define new PAR specific metadata around signing/encryption of the 
>> request object.
>>
>>  
>>
>> On Mon, Apr 27, 2020 at 2:35 AM Filip Skokan  wrote:
>>
>> Considering there's going to be a setting that forces clients to use PAR 
>> (other mailinglist thread), then we should rely on the existing 
>> `request_object_signing_alg` presence to indicate a Request Object must be 
>> used (as suggested by this upcoming OIDC Core errata), regardless of it 
>> being PAR or JAR. I don't see the need for a PAR specific metadata, for one 
>> - implementations wouldn't be easily able to re-use of existing pipelines, 
>> two - yes the contexts differ but do you think clients will be using both 
>> channels at the same time? And even if so, the Request Object is the same 
>> therefore its applicable to both channels the same.
>>
>>
>> Best,
>> Filip Skokan
>>
>>  
>>
>>  
>>
>> On Sun, 26 Apr 2020 at 17:09, Torsten Lodderstedt 
>>  wrote:
>>
>> Hi all, 
>>
>> this is one of the topics we quickly flipped through in the virtual meeting 
>> last week. 
>>
>> I see the following open questions:
>> - Can the client require its instances to use request objects only.
>> - Are there further requirements on the properties of these objects? Signed 
>> only, Signed and encrypted, algorithms? 
>> - Can an AS require ALL clients to use request objects only? 
>> - Further requirements here as well? 
>> - Is this tied to PAR or relevant for JAR as well? 
>>
>> In my opinion, client as well as AS should be able to control enforced use 
>> of request objects. 
>>
>> I could imagine the setting for JAR request objects (“request" parameter) 
>> and request objects in the PAR context differ, as the first case goes 
>> through the user’s browser whereas the PAR case goes direct from client to 
>> AS via a TLS protected channel. I therefore feel the settings should be PAR 
>> specific. 
>>
>> What do you think?
>>
>> best 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
>>
>>
>> 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

-- 
Vladimir Dzhuvinov




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

Re: [OAUTH-WG] OAuth GREASE

[Vladimir Dzhuvinov]

I get your frustration with PKCE. It would be a bad policy and example
to burden compliant ASes with additional stuff just because a few AS
implementations are not complying with the spec. It's not fair and can
end up creating all sorts of bad incentives in future.

Vladimir

On 22/04/2020 10:29, Neil Madden wrote:
> Section 3.1 of RFC 6749 says (of the authorization endpoint):
>
> The authorization server MUST ignore
>unrecognized request parameters.
> We hoped to be able to use this to opportunistically apply PKCE -
> always send a code_challenge in the hope that the AS supports it and
> there should be no harm if it doesn’t. 
> Sadly I learned yesterday of yet another public AS that fails hard if
> the request contains unrecognised parameters. It appears this part of
> the spec is widely ignored. 
> Given that this hampers the ability to add new request parameters in
> future, do we need our own GREASE to prevent these joints rusting tight?
> https://www.rfc-editor.org/rfc/rfc8701.html 
> 
> — Neil



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

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

[Vladimir Dzhuvinov]

Nat, John, thanks for updating the JAR spec. I just reviewed it, in
particular the authz request and the security considerations sections.
Choosing to make client_id (as top-level parameter) mandatory for all
cases, even for those when it can be readily extracted from the JWT,
makes the job of implementers even easier.


I have just one comment about the last paragraph in section 5, assuming
backward compatibility means with RFC6749 requests. Here is my proposed
wording:

The client MAY send the parameters included in the request object 
duplicated in the query parameters. For instance, this can be done 
to ensure the minimal required query parameters for an OAuth 2.0 
[RFC6749] authorization request are also present. An authorization 
server supporting this specification MUST however only use the 
parameters included in the request object.


Vladimir


On 19/04/2020 21:30, internet-dra...@ietf.org wrote:
> 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   : The OAuth 2.0 Authorization Framework: JWT Secured 
> Authorization Request (JAR)
> Authors : Nat Sakimura
>   John Bradley
>   Filename: draft-ietf-oauth-jwsreq-21.txt
>   Pages   : 31
>   Date: 2020-04-19
>
> Abstract:
>The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>query parameter serialization, which means that Authorization Request
>parameters are encoded in the URI of the request and sent through
>user agents such as web browsers.  While it is easy to implement, it
>means that (a) the communication through the user agents are not
>integrity protected and thus the parameters can be tainted, and (b)
>the source of the communication is not authenticated.  Because of
>these weaknesses, several attacks to the protocol have now been put
>forward.
>
>This document introduces the ability to send request parameters in a
>JSON Web Token (JWT) instead, which allows the request to be signed
>with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
>(JWE) so that the integrity, source authentication and
>confidentiality property of the Authorization Request is attained.
>The request can be sent by value or by reference.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-21
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-21
>
>
> 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/
>



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

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

[Vladimir Dzhuvinov]

On 16/04/2020 10:10, Dominick Baier wrote:
> *iat vs nbf*
> What’s the rationale for using iat instead of nbf. Aren’t most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?

Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my private observation). So given the empirical
approach of Vittorio to the spec, I suspect that's how "iat" got here.

If we bother to carefully look at the JWT spec we'll see that "iat" is
meant to be "informational" whereas it's "nbf" that is intended to serve
(together with "exp") in determining the actual validity window of the JWT.

https://tools.ietf.org/html/rfc7519#section-4.1.5

My suggestion is to require either "iat" or "nbf". That shouldn't break
anything, and deployments that rely on one or the other to determine the
validity window of the access token can continue using their preferred
claim for that.

Vladimir



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

Re: [OAUTH-WG] PAR and client metadata

[Vladimir Dzhuvinov]

In a off-list conversation Torsten floated the idea of letting
confidential PAR-only clients register without a redirect_uris and
having this "PAR only" parameter will enable that.

A "PAR only" parameter will also prevent client developers from
accidentally making plain authz requests (for clients that rely on PAR
for the extra security).

Vladimir

On 16/04/2020 18:39, Brian Campbell wrote:
>
>
> On Wed, Apr 15, 2020 at 1:44 PM Richard Backman, Annabelle
>  <mailto:40amazon@dmarc.ietf.org>> wrote:
>
> As I think through this, I’m struggling to identify the threats
> this actually helps mitigate.
>
> A client metadata parameter implies that the value may be
> different for different clients, and that any given client won’t
> already know via other means whether or not it needs to use PAR.
> That means we’re only talking about dynamic clients since
> statically registered clients already have some proprietary
> out-of-band registration mechanism (e.g., a developer console).
>
>
> As I tried to articulate in the original email and Filip also
> mentioned in a different fork of this email thread, defining metadata
> can be beneficial even when it's not used dynamically at runtime. So
> we're not only talking about dynamic clients.
>
>  
>
>
> A client metadata parameter also implies that the AS allows some
> clients to make non-PAR requests (otherwise it would be an AS
> metadata parameter).
>
>
> A per client setting seems necessary for existing ASs to roll out PAR
> support over time or just generally in support of diverse client
> capabilities and requirements.
>
>  
>
> If that’s the case then presumably a malicious party could
> register their own client that doesn’t use PAR.
>
> So it seems to me that the only scenario that this parameter would
> protect against is a malicious party impersonating a dynamically
> registered client that uses PAR. That wouldn’t apply to Mix-Up,
> since in that attack the attacker uses its own client.
>
>
> This client metadata parameter is meant to be something that would
> prevent a malicious actor from controlling the content of the authz
> request parameters, which could be done by crafting the link and
> tricking a user into following it. I mentioned mix-up as an example
> because the first variant of it desribed at
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> does something along those lines.
>
>  
>
>
> If a client can do PAR, then it can do authorization code grant
> and PKCE, so we’re further limited to scenarios where the attacker
> does not need to be able to redeem the authorization code
> themselves. What threats fall into this category?
>
> —
> Annabelle Backman (she/her)
> AWS Identity
>
>> On Apr 14, 2020, at 2:44 PM, Brian Campbell
>> > <mailto:40pingidentity@dmarc.ietf.org>> wrote:
>>
>> 
>>
>> *CAUTION*: This email originated from outside of the
>> organization. Do not click links or open attachments unless you
>> can confirm the sender and know the content is safe.
>>
>>
>> I was hoping to get to a rough consensus in support of the idea
>> before coming up with a name that everyone will hate :)
>>
>> In the meantime, however, name suggestions are of course welcome.
>>
>>
>> On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> I'm all for that.
>>
>> I suppose you have already thought of a suitable name? :)
>>
>> Vladimir
>>
>> On 14/04/2020 23:08, Brian Campbell wrote:
>>> Using PAR can facilitate improved security by giving clients
>>> a (relatively) simple means for sending a confidential,
>>> integrity protected, and (for confidential clients anyway)
>>> authenticated authorization request.
>>>
>>> It seems like some of that improved security could be
>>> undermined by a malicious actor somehow getting a user to
>>> navigate to a URL of a regular old parameterized
>>> authorization request. One variation of the Mix-Up Attack
>>> does this
>>> 
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
>>> 
>>> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4..1>
>>> for example and email, social media, onli

Re: [OAUTH-WG] PAR and client metadata

[Vladimir Dzhuvinov]

I'm all for that.

I suppose you have already thought of a suitable name? :)

Vladimir

On 14/04/2020 23:08, Brian Campbell wrote:
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity
> protected, and (for confidential clients anyway) authenticated
> authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a
> regular old parameterized authorization request. One variation of the
> Mix-Up Attack does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other
> ways a user might be tricked into following a maliciously crafted link. 
>
> Following from that it seems logical that an authorization server
> might want to restrict some clients from sending a regular
> parameterized authorization request and instead require use of the PAR
> endpoint to initiate an authorization request. Something like this
> could, of course, be implemented as custom policy or configuration in
> any AS. But I'm thinking it might be common enough to warrant adding a
> client metadata parameter to the PAR draft specifically for it. The
> metadata (and registered extensions) defined by Dynamic Client
> Registration [RFC7591] has come to imply a general data model and
> expected associated behaviors for clients that is useful for
> authorization server implementations, even when the Dynamic Client
> Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only
> use a request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> /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



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

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

[Vladimir Dzhuvinov]

+1 for DPoP

On 17/03/2020 14:25, Rob Otto wrote:
> I support adoption 
>
> Thank you
> Rob Otto
>
> On Tue, 17 Mar 2020 at 12:21, Rifaat Shekh-Yusef
> mailto:rifaat.i...@gmail.com>> wrote:
>
> 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 <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> -- 
> Ping Identity <https://www.pingidentity.com>  
> Rob Otto
> EMEA Field CTO/Solutions Architect
> roberto...@pingidentity.com <mailto:roberto...@pingidentity.com>
>
> c: +44 (0) 777 135 6092
>
> Connect with us:  Glassdoor logo
> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
> LinkedIn logo <https://www.linkedin.com/company/21870> twitter logo
> <https://twitter.com/pingidentity> facebook logo
> <https://www.facebook.com/pingidentitypage> youtube logo
> <https://www.youtube.com/user/PingIdentityTV> Blog logo
> <https://www.pingidentity.com/en/blog.html>
>
> <https://developer.pingidentity.com/en/signup.html>
>
> /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

-- 
Vladimir Dzhuvinov



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

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

[Vladimir Dzhuvinov]

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
>> mailto:jos...@authlete.com>> 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 request object)..
>> Ruling out that case makes security analysis
>> (particularly when creating new OAuth2 parameters)
>> significantly simpler.
>> > > 
>> > > Putting the iss in the JWE header and having the
>> client_id duplicated outside the request object seem to
>> address all the concerns I’ve seen raised.
>> > > 
>> > > (It seems like it may be unnecessary to have the
>> client_id duplicated outside if the request_uri is a PAR
>> one though.)
>> > > 
>> > > Joseph
>> > > 
>> > > 
>> > > 
>> > >> On 16 Jan 2020, at 22:40, John Bradley
>> mailto:ve7...@ve7jtb.com>> wrote:
>> > >> 
>> > >> I agree with the IESG reasoning that merging is
>> problimatic.  Once we
>> > >> allow that given a unknown list of possible
>> paramaters with diffrent
>> > >> security properties it would be quite difficult to
>> specify safely..
>> > >> 
>> > >> Query paramaters can still be sent outside the JAR,
>> but if they are in
>> > >> the OAuth registry the AS MUST ignore them.
>> > >> 
>> > >> Puting the iss in the JWE headder addresses the
>> encryption issue without
>> > >> merging.
>> > >> 
>> > >> I understand that some existing servers have
>> dependencys on getting the
>> > >> client

Re: [OAUTH-WG] Conflicting definitions in JWT Response for OAuth Token Introspection

[Vladimir Dzhuvinov]

a-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>    "iat":1532452100,
>>    "_token_data":{
>>       "active":false
>>    }
>> }
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>>
>> > On 4. Mar 2020, at 16:37, Justin Richer
>> mailto:jric...@mit.edu>> wrote:
>> >
>> > +1, this encapsulation is much cleaner.
>> >
>> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan
>> mailto:panva...@gmail.com>> wrote:
>> >>
>> >> Perhaps we should consider leaving the root level JWT
>> claims as-is per JWT and push the introspection response
>> unmodified as if it was regular json response to a JWT
>> claim called "introspection". Since regular introspection
>> uses the same claim names as JWT this would get around
>> all the conflicts.
>> >>
>> >> Last time i brought it up the authors didn't want to
>> consider it because of existing implementations.
>> >>
>> >> S pozdravem,
>> >> Filip Skokan
>> >>
>> >>
>> >> On Mon, 2 Mar 2020 at 07:52, Takahiko Kawasaki
>> mailto:t...@authlete.com>> wrote:
>> >> Thank you, Tatsuo Kudo, for showing me that Justin
>> Richer expressed the same concerns in this mailing list
>> about 6 months ago (on Sep. 4, 2019). RFC 8707 didn't
>> exist then, though.
>> >>
>> >> Re: [OAUTH-WG] Question regarding
>> draft-ietf-oauth-jwt-introspection-response-05
>> >>
>> 
>> https://mailarchive.ietf.org/arch/msg/oauth/LmMAxd35gW5Yox0j4MmU2rI_eUA/
>> >>
>> >> A JWT puts both (a) information about itself and (b)
>> other data in its payload part. When the "other data"
>> have the same claim names as are used to express
>> information about the JWT itself, conflicts happen.
>> >>
>> >> Also, it should be noted that Ben pointed out in other
>> thread that the requirement for "jti" in
>> draft-ietf-oauth-jwt-introspection-response, which says
>> "jti" is a unique identifier for the access token that
>> MUST be stable for all introspection calls, contradicts
>> the definition of "jti", which should be unique for each JWT.
>> >>
>> >> Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
>> draft-ietf-oauth-jwt-introspection-response-08: (with
>> DISCUSS and COMMENT)
>> >>
>> 
>> https://mailarchive.ietf.org/arch/msg/oauth/S4q7cF0TMZMzFO61I5M4QXCUWCM/
>> >>
>> >> draft-ietf-oauth-jwt-introspection-response needs to
>> be modified to solve the conflicts.
>> >>
>> >> Taka
>> >>
>> >> On Sun, Mar 1, 2020 at 4:10 PM Takahiko Kawasaki
>>  wrote:
>> >> Hello,
>> >>
>> >> I'm wondering if the following conflicts in "JWT
>> Response for OAuth Token Introspection" (draft 8) have
>> already been pointed out.
>> >>
>> >> RFC 8707 (Resource Indicators for OAuth 2.0) requires
>> that 'aud' in an introspection response hold the values
>> of the 'resource' request parameters, whereas "JWT
>> Response for OAuth Token Introspection" says that 'aud'
>> MUST identify the resource server receiving the token
>> introspection response. The definitions conflict.
>> >>
>> >> RFC 7662 (OAuth 2.0 Token Introspection) requires that
>> 'iat' in an introspection response indicate when the
>> access/refresh token was issued, whereas "JWT Response
>> for OAuth Token Introspection" says that 'iat' indicates
>> when the introspection response in JWT format was issued.
>> The definitions conflict.
>> >>
>> >> Best Regards,
>> >> Takahiko Kawasaki
>> >> Authlete, Inc.
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
-- 
Vladimir Dzhuvinov



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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt

[Vladimir Dzhuvinov]

Thanks Brian, we missed that entirely.

Have there been any thoughts on specifying a matching client reg
parameter for PKCE?

Vladimir

On 12/02/2020 01:19, Brian Campbell wrote:
> code_challenge_methods_supported is/was already defined in RFC 8414,
> it's just kinda easy to miss that it's there as you'd typically expect
> to find that sort of thing in the doc that defines PKCE itself. But
> PKCE (RFC 7636) predates AS metadata (RFC 8414) so things are
> different in that case.
>
> I notice too that draft-ietf-oauth-security-topics-14 still
> erroneously has RFC 8418 as the reference next to
> code_challenge_methods_supported where it should be RFC 8414. 
>
> On Tue, Feb 11, 2020 at 11:43 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Fantastic, we now have "code_challenge_methods_supported" defined
> for AS
> metadata and it's a MUST. Long overdue.
>
> Vladimir
>
> On 10/02/2020 20:14, internet-dra...@ietf.org
> <mailto:internet-dra...@ietf.org> wrote:
> > 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-14.txt
> >       Pages           : 46
> >       Date            : 2020-02-10
> >
> > 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 are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-14
> >
> > A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-14
> >
> >
> > 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 <http://tools.ietf.org>.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> >
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>



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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-14.txt

[Vladimir Dzhuvinov]

Fantastic, we now have "code_challenge_methods_supported" defined for AS
metadata and it's a MUST. Long overdue.

Vladimir

On 10/02/2020 20:14, internet-dra...@ietf.org wrote:
> 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-14.txt
>   Pages   : 46
>   Date: 2020-02-10
>
> 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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-14
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-14
>
>
> 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/
>
> ___
>




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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Vladimir Dzhuvinov]

On 14/01/2020 06:46, Benjamin Kaduk wrote:
> On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
>> To be clear, I’m not saying we suggest a particular form, and I agree that 
>> we shouldn’t specify that “it’s a JWT” or something of that nature. But if 
>> we call the result of PAR “thing X” and the target of request_uri “thing X” 
>> in JAR, then we’re compatible without saying what “thing X” needs to be in 
>> all cases. 
>>
> That seems fair.  What properties would a given "thing X" need to have in
> order to work, though -- uniqueness over a specific period of time?
> Unpredictability?  More?

 1. That the request_uri uniquely points to the submitted authZ request
for the duration of the request_uri lifetime (defined by the
expires_in response parameter).
 2. The request_uri cannot be reasonably guessed.

I think that's all we need Ben.

Vladimir




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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Vladimir Dzhuvinov]

On 13/01/2020 19:32, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree
> that we shouldn’t specify that “it’s a JWT” or something of that
> nature. But if we call the result of PAR “thing X” and the target of
> request_uri “thing X” in JAR, then we’re compatible without saying
> what “thing X” needs to be in all cases.

Good, we're on the same page then.

How about simply saying that the result of PAR is an URI referencing the
pushed authZ request; at the authZ endpoint its processing is completed.

No need is both clear and abstract enough to not require a form to be
specified.


> In cases where you do a remote look up, we want “thing X” to be
> formatted as a JWT.

But why?

Both PAR and authZ endpoints belong to the AS, which makes that impl
specific. The URI is the contract, between client and AS.

The AS, if uService based, could choose to implement that as CBOR Web
Token, or some other verifiable blob, resulting in the same essential
function, and this isn't affecting the client <-> AS contract in any way.


> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I
> believe that’s been backed off now and made conditional.

That was precisely my point.

Vladimir



>  — Justin
>
>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> My suggestion is to abstain from specifying the concrete form of the
>> resource pointed to by the PAR URI. Regardless of URI type (URN,
>> downloadable https URL or something else), and even if the PAR
>> endpoint and the authZ endpoint are managed by two different entities
>> (microservice or other scenario).
>>
>> In the Connect2id implementation of PAR the returned URI doesn't
>> point to a request object and it doesn't point to a JWT either. It
>> points to an internally stored "pre-processed" authZ request, which
>> the authZ endpoint then picks up to complete the authZ.
>>
>> Even if we eventually end up in microservice world, or allow the PAR
>> endpoint to be managed by some external entity, the PAR URI - its
>> interpretation, validation and potentially resource retrieval (JWT or
>> other blob), is an "internal contract" on the AS side. This doesn't
>> concern the client, and in OAuth 2.0 the role of AS is indivisible.
>>
>>
>> I see PAR request + authZ request as one logical OAuth 2.0 authZ
>> request: the client submits an authZ request and gets an authZ
>> response at the end. The URI is necessary for the client to proceed
>> from the 1st to the 2nd step. If we manage to frame / word the PAR
>> URI in this logical way, without getting stuck in the JAR definition
>> / framing of what the request_uri / object is, it would be great.
>>
>>
>> The normative language I think should focus on maintaining the OAuth
>> 2.0 contract for the entire logical authZ request, together with the
>> basic contracts of 1) JAR and the 2) authZ endpoint.
>>
>>
>> Vladimir
>>
>>
>> On 10/01/2020 22:55, Justin Richer wrote:
>>> So we could solve this by saying the resulting data object of a PAR
>>> is a request object. Which might also contain a request object
>>> internally as well. In that case JAR should back off from saying
>>> it’s a JWT and instead say it’s a request object. Or we define a new
>>> term for this authorization request blob thing.
>>>
>>> Or PAR could at least say that if it’s dereferenced over a remote
>>> protocol then it MUST be a JWT, but otherwise it can be whatever you
>>> want. That’s where the real interop concerns come in.
>>>
>>>  — Justin
>>>
>>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle
>>>> >>> <mailto:richanna=40amazon@dmarc.ietf.org>> wrote:
>>>>
>>>> Correct. The problem becomes pretty clear in the context of PAR,
>>>> where the AS is generating and vending out the URI at the PAR
>>>> endpoint, and consuming it at the authorization endpoint. From an
>>>> interoperability standpoint, it’s analogous to the AS vending an
>>>> authorization code at the authorization endpoint and consuming it
>>>> at the token endpoint.
>>>> – 
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>>  
>>>>  
>>>> *From: *John Bradley mailto:ve7...@ve7jtb.com>>
>>>> *Date: *Friday, January 10, 2020 at 12:29 PM
>>>> *To: *Brian Campbell >>> <mailt

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

[Vladimir Dzhuvinov]

John, thanks, much appreciated!

On 11/01/2020 21:36, John Bradley wrote:
>
> Yes JAR is not prohibiting paramater replication in the header. 
>
> I will see if i can add something in final edits to call that out.
>
> John B.
>
> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote:
>>
>> Thanks Mike for the rfc7519 section-5.3
>> <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this
>> parameter replication be used for client_id or the client_id ass
>> "iss" even though it isn't explicitly mentioned in the JAR spec?
>>
>> On 11/01/2020 02:58, John Bradley wrote:
>>> Right we just don't say to put the iss there in OIDC if it's
>>> symetricly encrypted.
>>
>> OIDC doesn't have the symmetric key selection issue, I suppose that
>> why the possibility to replicate params to the JWE header isn't
>> mentioned at all. OIDC requires the top-level query params to
>> represent a valid OAuth 2.0 request, and there client_id is required.
>> If the client_id is present the client registration together with any
>> present client_secret can be retrieved.
>>
>> I reread the JAR spec, this is the only place that mentions handling
>> of symmetric JWE.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2
>>
>>>(b)  Verifying that the symmetric key for the JWE encryption is the
>>> correct one if the JWE is using symmetric encryption.
>>
>>
>> Vladimir
>>
>>
>>>
>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones
>>> mailto:michael.jo...@microsoft.com>>
>>> wrote:
>>>
>>> The technique of replicating JWT claims that need to be publicly
>>> visible in an encrypted JWT in the header is defined at
>>> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to
>>> Dick Hardt for bringing this need to my attention as we were
>>> finishing the JWT spec.)
>>>
>>>  
>>>
>>>    -- Mike
>>>
>>>  
>>>
>>> *From:* OAuth >> <mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley
>>> *Sent:* Friday, January 10, 2020 2:15 PM
>>> *To:* Vladimir Dzhuvinov >> <mailto:vladi...@connect2id.com>>
>>> *Cc:* IETF oauth WG mailto:oauth@ietf.org>>
>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
>>> Request (JAR) vs OIDC request object
>>>
>>>  
>>>
>>> The intent was to do that, but specs change once the OAuth WG
>>> and IESG get there hands on them.  
>>>
>>>  
>>>
>>> Being backwards compatible with OIDC is not a compelling
>>> argument to the IESG.
>>>
>>>  
>>>
>>> We were mostly thinking of asymmetric encryption.  
>>>
>>>  
>>>
>>> Specifying puting the issuer and or the audience in the headder
>>> has come up in the past but probably is not documented.  
>>>
>>>  
>>>
>>> John B 
>>>
>>>  
>>>
>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
>>> mailto:vladi...@connect2id.com>> wrote:
>>>
>>> Yes, putting the client_id into the JWE header is a way
>>> around the need
>>> to have the client_id outside the JWE as top-level authZ
>>> request parameter.
>>>
>>> Unfortunately this work around isn't mentioned anywhere, I
>>> just checked
>>> the most recent draft-ietf-oauth-jwsreq-20.
>>>
>>> Our DDoS attack mitigation (for OIDC request_uri) also
>>> relies on the
>>> presence of client_id as top-level parameter, together with
>>> requiring
>>> RPs to register their request_uri's (so that we don't need
>>> to build and
>>> store an index of all request_uri's). I just had a look at
>>> "DDoS Attack
>>> on the Authorization Server" and also realised the request_uri
>>> registration isn't explicitly mentioned as attack prevention
>>> ("the
>>> server should (a) check that the value of "request_uri"
>>> parameter does
>>> not point to an unexpected location").
>>>
>>&g

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Vladimir Dzhuvinov]

nicate the pushed request to the authorization endpoint.
>>>>>>>     >     • According to JAR, the resource referenced by
>>>>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>>>>     >     • Request Object is defined to be a JWT containing
>>>>>>> all the authorization request parameters. (Section 2.1)
>>>>>>>     >  
>>>>>>> > There is no need for this requirement to support
>>>>>>> interoperability, as this is internal to the AS. It is also
>>>>>>> inconsistent with the rest of JAR, which avoids attempting to
>>>>>>> define the internal communications between the two AS endpoints.
>>>>>>> Worse, this restriction makes it harder for the authorization
>>>>>>> endpoint to leverage validation and other work performed at the
>>>>>>> PAR endpoint, as the state or outcome of that work must be
>>>>>>> forced into the JWT format (or retrieved via a subsequent
>>>>>>> service call or database lookup).
>>>>>>>     >  
>>>>>>> > – 
>>>>>>> > Annabelle Richard Backman
>>>>>>>     > AWS Identity
>>>>>>>     >  
>>>>>>> > ___
>>>>>>>     > 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
>>>>>
>>>>> */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./*
>>>
>>> */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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov



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

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

[Vladimir Dzhuvinov]

Thanks Mike for the rfc7519 section-5.3
<https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can this
parameter replication be used for client_id or the client_id ass "iss"
even though it isn't explicitly mentioned in the JAR spec?

On 11/01/2020 02:58, John Bradley wrote:
> Right we just don't say to put the iss there in OIDC if it's
> symetricly encrypted.

OIDC doesn't have the symmetric key selection issue, I suppose that why
the possibility to replicate params to the JWE header isn't mentioned at
all. OIDC requires the top-level query params to represent a valid OAuth
2.0 request, and there client_id is required. If the client_id is
present the client registration together with any present client_secret
can be retrieved.

I reread the JAR spec, this is the only place that mentions handling of
symmetric JWE.

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2

>(b)  Verifying that the symmetric key for the JWE encryption is the
> correct one if the JWE is using symmetric encryption.


Vladimir


>
> On Fri, Jan 10, 2020, 9:41 PM Mike Jones  <mailto:michael.jo...@microsoft.com>> wrote:
>
> The technique of replicating JWT claims that need to be publicly
> visible in an encrypted JWT in the header is defined at
> https://tools.ietf.org/html/rfc7519#section-5.3.  (Thanks to Dick
> Hardt for bringing this need to my attention as we were finishing
> the JWT spec.)
>
>  
>
>    -- Mike
>
>  
>
> *From:* OAuth  <mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley
> *Sent:* Friday, January 10, 2020 2:15 PM
> *To:* Vladimir Dzhuvinov  <mailto:vladi...@connect2id.com>>
> *Cc:* IETF oauth WG mailto:oauth@ietf.org>>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured Authorization
> Request (JAR) vs OIDC request object
>
>  
>
> The intent was to do that, but specs change once the OAuth WG and
> IESG get there hands on them.  
>
>  
>
> Being backwards compatible with OIDC is not a compelling argument
> to the IESG.
>
>  
>
> We were mostly thinking of asymmetric encryption.  
>
>  
>
> Specifying puting the issuer and or the audience in the headder
> has come up in the past but probably is not documented.  
>
>  
>
> John B 
>
>  
>
> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Yes, putting the client_id into the JWE header is a way around
> the need
> to have the client_id outside the JWE as top-level authZ
> request parameter.
>
> Unfortunately this work around isn't mentioned anywhere, I
> just checked
> the most recent draft-ietf-oauth-jwsreq-20.
>
> Our DDoS attack mitigation (for OIDC request_uri) also relies
> on the
> presence of client_id as top-level parameter, together with
> requiring
> RPs to register their request_uri's (so that we don't need to
> build and
> store an index of all request_uri's). I just had a look at
> "DDoS Attack
> on the Authorization Server" and also realised the request_uri
> registration isn't explicitly mentioned as attack prevention ("the
> server should (a) check that the value of "request_uri"
> parameter does
> not point to an unexpected location").
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1
> 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D=0>
>
> To be honest, I feel quite bad about the situation with JAR we
> are in
> now. For some reason I had the impression that OAuth JAR was
> going to be
> the OIDC request / request_uri for general OAuth 2.0 use, as
> with other
> OIDC bits that later became general purpose OAuth 2.0 specs.
>
> I find it unfortunate I didn't notice this when I was
> reviewing the spec
> in the past.
>
> Vladimir
>
>
> On 10/01/2020 22:39, Filip Skokan wrote:
> > Vladimir,
> >
> > For that very case the payload claims may be repeated in the
> JWE protected header. An imp

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

[Vladimir Dzhuvinov]

Yes, putting the client_id into the JWE header is a way around the need
to have the client_id outside the JWE as top-level authZ request parameter.

Unfortunately this work around isn't mentioned anywhere, I just checked
the most recent draft-ietf-oauth-jwsreq-20.

Our DDoS attack mitigation (for OIDC request_uri) also relies on the
presence of client_id as top-level parameter, together with requiring
RPs to register their request_uri's (so that we don't need to build and
store an index of all request_uri's). I just had a look at "DDoS Attack
on the Authorization Server" and also realised the request_uri
registration isn't explicitly mentioned as attack prevention ("the
server should (a) check that the value of "request_uri" parameter does
not point to an unexpected location").

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1

To be honest, I feel quite bad about the situation with JAR we are in
now. For some reason I had the impression that OAuth JAR was going to be
the OIDC request / request_uri for general OAuth 2.0 use, as with other
OIDC bits that later became general purpose OAuth 2.0 specs.

I find it unfortunate I didn't notice this when I was reviewing the spec
in the past.

Vladimir


On 10/01/2020 22:39, Filip Skokan wrote:
> Vladimir, 
>
> For that very case the payload claims may be repeated in the JWE protected 
> header. An implementation wanting to handle this may look for iss/client_id 
> there. 
>
> Odesláno z iPhonu
>
>> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov :
>>
>> I just realised there is one class of JARs where it's practially
>> impossible to process the request if merge isn't supported:
>>
>> The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
>> for that and specs a method for deriving the shared key from the
>> client_secret:
>>
>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption
>>
>> If the JAR is encrypted with the client_secret, and there is no
>> top-level client_id parameter, there's no good way for the OP to find
>> out which client_secret to get to try to decrypt the JWE. Unless the OP
>> keeps an index of all issued client_secret's.
>>
>>
>> OP servers which require request_uri registration
>> (require_request_uri_registration=true) and don't want to index all
>> registered request_uri's, also have no good way to process a request_uri
>> if the client_id isn't present as top-level parameter.
>>
>>
>> Vladimir
>>
>>
>>> On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>>>
>>>>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>>> I think Torsten is speculating that is not a feature people use.   
>>> I’m still trying to understand the use case for merging signed and unsigned 
>>> parameters. Nat once explained a use case, where a client uses parameters 
>>> signed by a 3rd party (some „certification authority“) in combination with 
>>> transaction-specific parameters. Is this being done in the wild? 
>>>
>>> PS: PAR would work with both modes.




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

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

[Vladimir Dzhuvinov]

I just realised there is one class of JARs where it's practially
impossible to process the request if merge isn't supported:

The client submits a JAR encrypted (JWT) with a shared key. OIDC allows
for that and specs a method for deriving the shared key from the
client_secret:

https://openid.net/specs/openid-connect-core-1_0.html#Encryption

If the JAR is encrypted with the client_secret, and there is no
top-level client_id parameter, there's no good way for the OP to find
out which client_secret to get to try to decrypt the JWE. Unless the OP
keeps an index of all issued client_secret's.


OP servers which require request_uri registration
(require_request_uri_registration=true) and don't want to index all
registered request_uri's, also have no good way to process a request_uri
if the client_id isn't present as top-level parameter.


Vladimir


On 10/01/2020 20:13, Torsten Lodderstedt wrote:
>
>> Am 10.01.2020 um 16:53 schrieb John Bradley :
>>
>> I think Torsten is speculating that is not a feature people use.   
> I’m still trying to understand the use case for merging signed and unsigned 
> parameters. Nat once explained a use case, where a client uses parameters 
> signed by a 3rd party (some „certification authority“) in combination with 
> transaction-specific parameters. Is this being done in the wild? 
>
> PS: PAR would work with both modes.




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

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

[Vladimir Dzhuvinov]

On 07/01/2020 00:22, Filip Skokan wrote:
> We've been discussing making the following change to the language
>
> The AS SHOULD validate the request in the same way as at the
> authorization endpoint. The AS MUST ensure that all parameters to
> the authorization request are still valid at the time when the
> request URI is used.
>
Could you expand a bit on the second sentence?

Alternative suggestion:

The AS MUST validate the request in the same way as at the authorization
endpoint, or complete the request validation at the authorization endpoint.

Vladimir


> This would allow the PAR endpoint to simply stash the encrypted
> request object instead of decrypting and validating it. All within the
> bounds of "SHOULD - We’d like you to do this, but we can’t always
> require it". This supports "light weight PAR" implementation rather
> than introducing the unnecessary complexity in the form of a second JWKS.
>
> Best,
> *Filip*
>
>
> On Mon, 6 Jan 2020 at 23:00, Richard Backman, Annabelle
>  > wrote:
>
> The issue isn’t that the PAR endpoint needs access to one specific
> request object decryption key that could reasonably be shared
> across AS endpoints, but that it actually needs access to the
> private keys for all encryption public keys in the JWK set pointed
> to by the AS’s jwks_uri metadata property. Since there is no way
> to designate one particular key as the one to use for encrypting
> request objects, clients may reasonably use any encryption public
> key in the JWK set to encrypt a request object. As one example of
> how this could expose sensitive data to the PAR endpoint, if the
> PAR endpoint has all the decryption keys for the keys in the AS’s
> JWK set, it would be able to decrypt ID Tokens sent in
> id_token_hint request parameters. As more and more use cases
> develop for encrypting blobs for the AS, this issue will only get
> worse.
>
>  
>
> The PAR endpoint can’t simply stash the encrypted request object,
> as it is required to verify the request, according to §2.1:
>
>  
>
> The AS MUST process the request as follows:
>
>  
>
> ...
>
>  
>
> 3.  The AS MUST validate the request in the same way as at the
>
>   authorization endpoint. ...
>
>  
>
> This language needs to be more flexible, IMHO, to allow for
> lightweight PAR endpoints that may not have the information or
> authority needed to perform all the validation that happens at the
> authorization endpoint. I need to think about this more before I
> can say if it would adequately address my concerns, but it’d be a
> good start and makes sense in its own right.
>
>  
>
> I think it’s pretty risky for us to base decision on an assumption
> that no one is going to need or want to encrypt pushed request
> objects, particularly when they’re JWTs, and JWTs have well
> established support for encryption, and encrypted JWTs are
> supported by pass-by-value in OIDC and draft-ietf-oauth-jwsreq.
> But if you insist, here are a few examples for why someone might
> want to do this:
>
>  1. The request object is passed by reference, and accessible on
> the public Internet.
>  2. The request object contains sensitive transaction-related data
> in RAR parameters that the client’s authN/authZ stack doesn’t
> need to have access to.
>  3. The AS requires request object encryption to minimize exposure
> to the hosted PAR endpoint service it uses.
>  4. #2, but the threat vector is gaps in end-to-end TLS.
>  5. Any of the above, but the concern is message integrity, and
> the AS requires requested objects to be encrypted for
> confidentiality and integrity protection and does not support
> signed request objects.
>
>  
>
> – 
>
> Annabelle Richard Backman
>
> AWS Identity
>
>  
>
>  
>
> *From: *Neil Madden  >
> *Date: *Monday, January 6, 2020 at 6:29 AM
> *To: *Brian Campbell  >
> *Cc: *"Richard Backman, Annabelle"  >, Nat Sakimura  >, Dave Tonge  >, Torsten Lodderstedt
> mailto:tors...@lodderstedt.net>>, oauth
> mailto:oauth@ietf.org>>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
>  
>
> Agreed.
>
>  
>
> In addition, I'm not sure why the PAR endpoint would need access
> to the decryption keys at all. If you're using encrypted request
> objects then the PAR endpoint receives an encrypted JWT and then
> later makes the same (still encrypted) JWT available to the
> authorization endpoint. If the PAR endpoint is doing any kind of
> decryption or validation on behalf of the authorization 

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR metadata

[Vladimir Dzhuvinov]

Just to comment that with a lightweight PAR (stash-only) endpoint one of
the nice benefits of PAR will be lost - to pre-validate the request
(client_id, redirect_uri, etc) as much as possible before a front-end
call is made and the user is sent to the authZ endpoint.

Vladimir

On 06/01/2020 23:59, Richard Backman, Annabelle wrote:
>
> The issue isn’t that the PAR endpoint needs access to one specific
> request object decryption key that could reasonably be shared across
> AS endpoints, but that it actually needs access to the private keys
> for all encryption public keys in the JWK set pointed to by the AS’s
> jwks_uri metadata property. Since there is no way to designate one
> particular key as the one to use for encrypting request objects,
> clients may reasonably use any encryption public key in the JWK set to
> encrypt a request object. As one example of how this could expose
> sensitive data to the PAR endpoint, if the PAR endpoint has all the
> decryption keys for the keys in the AS’s JWK set, it would be able to
> decrypt ID Tokens sent in id_token_hint request parameters. As more
> and more use cases develop for encrypting blobs for the AS, this issue
> will only get worse.
>
>  
>
> The PAR endpoint can’t simply stash the encrypted request object, as
> it is required to verify the request, according to §2.1:
>
>  
>
> The AS MUST process the request as follows:
>  
> ...
>  
> 3.  The AS MUST validate the request in the same way as at the
>   authorization endpoint. ...
>  
>
> This language needs to be more flexible, IMHO, to allow for
> lightweight PAR endpoints that may not have the information or
> authority needed to perform all the validation that happens at the
> authorization endpoint. I need to think about this more before I can
> say if it would adequately address my concerns, but it’d be a good
> start and makes sense in its own right.
>
>  
>
> I think it’s pretty risky for us to base decision on an assumption
> that no one is going to need or want to encrypt pushed request
> objects, particularly when they’re JWTs, and JWTs have well
> established support for encryption, and encrypted JWTs are supported
> by pass-by-value in OIDC and draft-ietf-oauth-jwsreq. But if you
> insist, here are a few examples for why someone might want to do this:
>
>  1. The request object is passed by reference, and accessible on the
> public Internet.
>  2. The request object contains sensitive transaction-related data in
> RAR parameters that the client’s authN/authZ stack doesn’t need to
> have access to.
>  3. The AS requires request object encryption to minimize exposure to
> the hosted PAR endpoint service it uses.
>  4. #2, but the threat vector is gaps in end-to-end TLS.
>  5. Any of the above, but the concern is message integrity, and the AS
> requires requested objects to be encrypted for confidentiality and
> integrity protection and does not support signed request objects.
>
>  
>
> – 
>
> Annabelle Richard Backman
>
> AWS Identity
>
>  
>
>  
>
> *From: *Neil Madden 
> *Date: *Monday, January 6, 2020 at 6:29 AM
> *To: *Brian Campbell 
> *Cc: *"Richard Backman, Annabelle" , Nat Sakimura
> , Dave Tonge , Torsten
> Lodderstedt , oauth 
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR metadata
>
>  
>
> Agreed.
>
>  
>
> In addition, I'm not sure why the PAR endpoint would need access to
> the decryption keys at all. If you're using encrypted request objects
> then the PAR endpoint receives an encrypted JWT and then later makes
> the same (still encrypted) JWT available to the authorization
> endpoint. If the PAR endpoint is doing any kind of decryption or
> validation on behalf of the authorization endpoint then they are
> clearly not in separate trust boundaries.
>
>  
>
> -- Neil
>
>  
>
>
>
> On 6 Jan 2020, at 13:57, Brian Campbell
>  > wrote:
>
>  
>
> I really struggle to see the assumption that an entity be able to
> use the same key to decrypt the same type of message ultimately
> intended for the same purpose as an artificial limit. The same
> general assumption   underlies everything else in OAuth/OIDC
> (Vladimir's post points to some but not all examples of such).
> There's no reason for PAR to make a one-off exception. And should
> there be some deployment specific reason that truly requires that
> kind of isolation, there are certainly implementation options that
> aren't compatibility-breaking. And having said all that, I'm
> honestly a little surprised anyone is thinking much about
> encrypted request objects with PAR as, at least with my limited
> imagination, there's not really a need for it.
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
> On Fri, Jan 3, 2020 at 2:43 PM Richard Backman, Annabelle
>  > wrote:
>
> PAR introduces an added 

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests

[Vladimir Dzhuvinov]

+1 for the adoption of RAR

On 06/01/2020 21:37, Rifaat Shekh-Yusef wrote:
> This is a call for adoption for the *OAuth 2.0 Rich Authorization
> Requests* document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ 



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

Re: [OAUTH-WG] PAR metadata

[Vladimir Dzhuvinov]

Hi Annabelle,

We recently implemented PAR in a release. What security risks do AS
users face if the clients encrypt to the same JWK set?

If there are general issues with that, do they also hold for clients?
Because an OP / AS can potentially issue multiple types of encrypted
JWTs at separate endpoints:

  * Encrypted ID tokens
  * Encrypted UserInfo
  * Encrypted authZ responses (JARM)
  * Encrypted introspection responses

I like PAR because it was so easy and straightforward to explain to
client developers, and the benefits of having an authZ request submitted
directly to the AS were also easily understood (no limits on the size of
the request and it remaining hidden from the front-channel, the client
is authenticated before user auth / consent).

Vladimir

On 03/01/2020 23:43, Richard Backman, Annabelle wrote:
> PAR introduces an added wrinkle for encrypted request objects: the PAR 
> endpoint and authorization endpoint may not have access to the same 
> cryptographic keys, even though they're both part of the "authorization 
> server." Since they're different endpoints with different roles, it's 
> reasonable to put them in separate trust boundaries. There is no way to 
> support this isolation with just a single "jwks_uri" metadata property.
>
> The two options that I see are:
>
> 1. Define a new par_jwks_uri metadata property.
> 2. Explicitly state that this separation is not supported.
>
> I strongly perfer #1 as it has a very minor impact on deployments that don't 
> care (i.e., they just set par_jwks_uri and jwks_uri to the same value) and 
> failing to support this trust boundary creates an artificial limit on 
> implementation architecture and could lead to compatibility-breaking 
> workarounds.
>
> – 
> Annabelle Richard Backman
> AWS Identity
>  
>
> On 12/31/19, 8:07 AM, "OAuth on behalf of Torsten Lodderstedt" 
>  torsten=40lodderstedt@dmarc.ietf.org> wrote:
>
> Hi Filip, 
> 
> > On 31. Dec 2019, at 16:22, Filip Skokan  wrote:
> > 
> > I don't think we need a *_auth_method_* metadata for every endpoint the 
> client calls directly, none of the new specs defined these (e.g. device 
> authorization endpoint or CIBA), meaning they also didn't follow the scheme 
> from RFC 8414 where introspection and revocation got its own metadata. In 
> most cases the unfortunately named `token_endpoint_auth_method` and its 
> related metadata is what's used by clients for all direct calls anyway.
> > 
> > The same principle could be applied to signing (and encryption) 
> algorithms as well.
> > 
> > This I do not follow, auth methods and their signing is dealt with by 
> using `token_endpoint_auth_methods_supported` and 
> `token_endpoint_auth_signing_alg_values_supported` - there's no encryption 
> for the `_jwt` client auth methods. 
> > Unless it was meant to address the Request Object signing and 
> encryption metadata, which is defined and IANA registered by OIDC. PAR only 
> references JAR section 6.1 and 6.2 for decryption/signature validation and 
> these do not mention the metadata (e.g. request_object_signing_alg) anymore 
> since draft 07.
> 
> Dammed! You are so right. Sorry, I got confused somehow. 
> 
> > 
> > PS: I also found this comment related to the same question about auth 
> metadata but for CIBA.
> 
> Thanks for sharing. 
> 
> > 
> > Best,
> > Filip
> 
> thanks,
> Torsten. 
> 
> > 
> > 
> > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt 
>  wrote:
> > Hi all,
> > 
> > Ronald just sent me an email asking whether we will define metadata for 
> > 
> > pushed_authorization_endpoint_auth_methods_supported and
> > pushed_authorization_endpoint_auth_signing_alg_values_supported.
> > 
> > The draft right now utilises the existing token endpoint authentication 
> methods so there is basically no need to define another parameter. The same 
> principle could be applied to signing (and encryption) algorithms as well. 
> > 
> > What’s your opinion?
> > 
> > best regards,
> > Torsten.
> 
> 
>



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

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

[Vladimir Dzhuvinov]

Why not leave this to be an AS policy, or to be defined by specific
profiles?

We have had a simple AS setting which allows or prohibits parameters
outside the JWT:

  * If parameters outside the JWT are allowed, they are merged, with the
JWT-secured ones having precedence.

  * If parameters outside the JWT are prohibited, and any are found, an
invalid_request error with message is returned.

This allowed us to handle OpenID requests in applications requiring all
parameters to be signed. I believe the FAPI profile also has this
requirement. But there can well be applications and scenarios where some
of the parameters (e.g. client_id, scope, redirect_uri) may need to be
pre-signed / made invariable by some 3rd party, while leaving state and
PKCE be set by the client.

My concern is not so much about the backward compatibility, but that
we're trying to make a decision which seems to be better left to JAR
applications and profiles.

Letting the AS decide on the merge or not-merge is my preference.

Vladimir

On 02/01/2020 19:35, Justin Richer wrote:
> For solution [2], this is the behavior that’s required for OIDC today,
> so I would say that’s the New Client behaving like an Old Client in
> order to talk to an Old Server. So in reality, (2) causes the request
> to be rejected, and that’s OK.
>
> I don’t think it’s viable to require parameters to exist inside the
> request object at all times. Nor should we try to enumerate which
> parameters go inside and outside at all times — at least from the
> JAR/OAuth level of things. I think there are too many things that are
> application and deployment specific for us to make this call. The very
> nature of the request object changes for people — some have a static
> object that’s deployed with clients and some have something that the
> client creates at runtime for each request. 
>
> If the instead the New Server requires that any parameters duplicated
> between the two places have to match (the OIDC method) or that in a
> conflict the request object values take precedence (the merge method),
> then problems 3-1 and 3-2 go away. 
>
> With the merge-and-precedence behavior, which is what I thought that
> JAR had during WGLC, [3-1] is well-defined. The request is processed
> the same way every time because this is a New Server. The client is
> going to do OIDC’s “duplicate” method, so “merge with precedence” is
> effectively a no-op.
>
> With the merge-and-precedence behavior, [3-2] doesn’t happen because
> the required parameters aren’t required to be in the request object
> itself. As long as the request object is valid, it protects all
> parameters within it. I don’t think it’s up to us to determine what
> makes sense to put in that object. Security guidance is probably a
> good idea here.
>
> Solution [3] is what Old Clients already do in OIDC today, so that’s
> what already happens and why problem space (3) isn’t a problem.
>
>  — Justin
>
>> On Jan 2, 2020, at 12:24 PM, Takahiko Kawasaki > > wrote:
>>
>> Thank you, Justin. Actually, I wanted to see someone write a summary
>> about what happens in each combination from a viewpoint of both RP
>> and AS with regard to backward compatibility (as I told you in other
>> channel just before you posted your email ^_^).
>>
>> So,
>>
>> *(1) New Client + New Server*
>> No problem will happen.
>>
>> *(2) New Client + Old Server*
>> *[Problem 2-1]* If an authorization request contains 'request' or
>> 'request_uri' but doesn't have old mandatory request parameters
>> ('client_id' and 'response_type') outside the request object, the
>> request is rejected.
>>
>> *[Solution 2]* New Client should include the old mandatory request
>> parameters duplicately outside the request object. This means that
>> New Client should always send old mandatory request parameters
>> duplicately outside the request object if it wants to get maximum
>> compatibility.
>>
>> *(3) Old Client + New Server*
>> *[Problem 3-1]* If an authorization request contains 'request' or
>> 'request_uri' and some "optional" request parameters are not included
>> in the request object, AS will interpret the request differently.
>> Imagine what happens when optional parameters such as 'scope',
>> 'state', 'nonce', 'redirect_uri', 'response_mode', 'max_age',
>> 'acr_values', 'code_challenge', 'code_challenge_method' and 'prompt'
>> are not included in the request object but present outside the
>> request object.
>>
>> *[Problem 3-2]* If an authorization request contains 'request' or
>> 'request_uri' and some "mandatory" request parameters ('client_id'
>> and 'response_type') are not included in the request object, the
>> request is rejected.
>>
>> *[Solution 3]* Old Client should include all request parameters
>> duplicately in the request object. This means that Old Client should
>> always include all request parameters duplicately in the request
>> object if it wants to get maximum compatibility.
>>
>> *(4) Old Client + Old 

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

[Vladimir Dzhuvinov]

+1 for the PAR spec adoption. We were in fact so pleased with PAR that
next week we'll be making it available for production use, based on
draft-lodderstedt-oauth-par-01. If we had any questions during the
implementation, they were addressed in -01. The spec is feature complete
IMHO.

Vladimir

On 17/12/2019 14:59, Rifaat Shekh-Yusef wrote:
> All,
>
> This is a call for adoption of for the OAuth 2.0 Pushed Authorization
> Requests document.
> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/ 
>
> There was a good support for this document during the Singapore
> meeting, and on the mailing list in the Meeting Minutes thread.
>
> Please, let us know if you support or object to adopting this document
> as a working group document by Dec 27th.
>
> If you have already indicated your support on the Meeting Minutes
> thread, you do not need to do it again on this thread.
>
> Regards,
>  Rifaat & Hannes

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

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-token-exchange (version 19)

[Vladimir Dzhuvinov]

From what I see -19 hasn't expired:

Expires: January 21, 2020


Perhaps somebody else could answer your second question, but for me it's
essentially at a stage when it's a done deal.

Vladimir

On 04/11/2019 20:26, Luke Synnestvedt (US - ADVS) wrote:
> Hello IETF OAuth team,
>
> I'm drafting some internal reference architecture guidance on the
> topic of Token Exchange within an OAuth 2.0
> authentication/authorization flow and have relied heavily on the most
> recent draft
>  which
> I know has since expired. I also see that this document has been sent
> for publication approval - is there an update from the team regarding
> when this document may be published?
>
> Thanks,
> Luke Synnestvedt



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