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

[Takahiko Kawasaki]

I support adoption.

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

Best Regards,
Takahiko Kawasaki


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

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

Re: [OAUTH-WG] Implementations - OAuth 2.0 Step-up Authentication Challenge Protocol

[Takahiko Kawasaki]

Hi Rifaat,

Authlete 2.3, which is planned to be released next month (January 2023),
supports OAuth 2.0 Step-up Authentication Challenge Protocol. I've
published an article on Authlete's website that explains the specification
in detail with many diagrams.

OAuth 2.0 Step-up Authentication Challenge Protocol
https://www.authlete.com/developers/stepup_authn/

Best Regards,
Takahiko Kawasaki


On Tue, Dec 20, 2022 at 10:15 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> As part of the shepherd write-up for the OAuth 2.0 Step-up Authentication
> Challenge Protocol document,
> we are looking for information about implementations of this draft.
>
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-08.html
>
> Please, reply to this email, on the mailing list, with any implementations
> that you are aware of to support this document.
>
> Regards,
> Rifaat
> ___
> 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] Step-up Auth: request acr as essential

[Takahiko Kawasaki]

s syntax should be inconsequential in this context.
>>
>> If you feel VERY strongly about it, we could add language in the
>> deployment considerations to preempt confusion on this point (e.g.
>> reminding people that the claims/essential mechanism defined in OIDC core
>> is meant to work w id_tokens and there are no guarantees it will have any
>> effect on ATs, if any). We'd rather not, mostly to adhere to the tenet of
>> simplicity, but we are interested in your take!
>>
>> Thanks
>> V.
>>
>>
>>
>>
>>> On Thu, Nov 3, 2022 at 3:50 PM Takahiko Kawasaki 
>>> wrote:
>>>
>>>> *This message originated outside your organization.*
>>>>
>>>> --
>>>>
>>>> Thank you.
>>>>
>>>> 1) The same points are true to "acr_values".
>>>>
>>>> 2) The expressive power and popularity don't have to stop the spec from
>>>> kindly mentioning the standardized way which was defined 8 years ago.
>>>>
>>>> Taka
>>>>
>>>> 2022年11月3日(木) 22:04 Vittorio Bertocci :
>>>>
>>>>> Hi Takahiko,
>>>>> thanks for the comment!
>>>>> The use of the claims parameter for this use case is tricky.
>>>>> 1) if used as is, requesting a particular acr via claims isn't
>>>>> guaranteed to have any effect on the content of an access token, if an
>>>>> access token is even present: OIDC only defines the claims as having an
>>>>> effect on id_token and/or userinfo.
>>>>> 2) pulling in the claims parameter here would vastly exceed the scope
>>>>> of this specification, as the expressive power of claims goes well beyond
>>>>> requesting acr (possibly one of the reasons for which it doesn't enjoy
>>>>> widespread support) and defining its effects on access tokens would 
>>>>> require
>>>>> a lot more work than what's needed to achieve the step up scenario.
>>>>> I hope this helps!
>>>>> Cheers,
>>>>> V.
>>>>> On Wed, Nov 2, 2022 at 10:30 AM Takahiko Kawasaki 
>>>>> wrote:
>>>>>
>>>>>> *This message originated outside your organization.*
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> If a client application wants to make the authorization server return
>>>>>> error=unmet_authentication_requirements when none of requested ACRs is
>>>>>> satisfied, the client application should request the "acr" claim as an
>>>>>> "essential" claim. A straightforward way is to embed
>>>>>> "acr":{"essential":true,"values":[...]} in the "claims" request parameter
>>>>>> (OIDC Core Section 5.5). (NOTE: the "acr_values" request parameter and 
>>>>>> the
>>>>>> "default_acr_values" client metadata cannot request claims as essential.)
>>>>>>
>>>>>> The draft of OAuth 2.0 Step-up Authentication Challenge Protocol
>>>>>> recommends that ACRs requested by the "acr_values" request parameter be
>>>>>> treated as required (= essential). The recommendation may be okay, but it
>>>>>> should be better for the specification to mention additionally that there
>>>>>> is a standardized way to request the "acr" claim as essential. That is, 
>>>>>> it
>>>>>> is better to introduce "acr":{"essential":true,"values":[...]} somewhere 
>>>>>> in
>>>>>> the specification.
>>>>>>
>>>>>> Best Regards,
>>>>>> Takahiko Kawasaki
>>>>>> ___
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!7JfV3rPtbY6zIZFPRwN30f70buuNs1WSBZIJ1vx5LBL5cXkhHMvSQpQpztdUVAc-TzcoRKGyRNTS$>
>>>>>>
>>>>> ___
>> 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] Step-up Auth: request acr as essential

[Takahiko Kawasaki]

Thank you.

1) The same points are true to "acr_values".

2) The expressive power and popularity don't have to stop the spec from
kindly mentioning the standardized way which was defined 8 years ago.

Taka

2022年11月3日(木) 22:04 Vittorio Bertocci :

> Hi Takahiko,
> thanks for the comment!
> The use of the claims parameter for this use case is tricky.
> 1) if used as is, requesting a particular acr via claims isn't guaranteed
> to have any effect on the content of an access token, if an access token is
> even present: OIDC only defines the claims as having an effect on id_token
> and/or userinfo.
> 2) pulling in the claims parameter here would vastly exceed the scope of
> this specification, as the expressive power of claims goes well beyond
> requesting acr (possibly one of the reasons for which it doesn't enjoy
> widespread support) and defining its effects on access tokens would require
> a lot more work than what's needed to achieve the step up scenario.
> I hope this helps!
> Cheers,
> V.
> On Wed, Nov 2, 2022 at 10:30 AM Takahiko Kawasaki 
> wrote:
>
>> *This message originated outside your organization.*
>>
>> --
>>
>> Hello,
>>
>> If a client application wants to make the authorization server return
>> error=unmet_authentication_requirements when none of requested ACRs is
>> satisfied, the client application should request the "acr" claim as an
>> "essential" claim. A straightforward way is to embed
>> "acr":{"essential":true,"values":[...]} in the "claims" request parameter
>> (OIDC Core Section 5.5). (NOTE: the "acr_values" request parameter and the
>> "default_acr_values" client metadata cannot request claims as essential.)
>>
>> The draft of OAuth 2.0 Step-up Authentication Challenge Protocol
>> recommends that ACRs requested by the "acr_values" request parameter be
>> treated as required (= essential). The recommendation may be okay, but it
>> should be better for the specification to mention additionally that there
>> is a standardized way to request the "acr" claim as essential. That is, it
>> is better to introduce "acr":{"essential":true,"values":[...]} somewhere in
>> the specification.
>>
>> Best Regards,
>> Takahiko Kawasaki
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Step-up Auth: request acr as essential

[Takahiko Kawasaki]

Hello,

If a client application wants to make the authorization server return
error=unmet_authentication_requirements when none of requested ACRs is
satisfied, the client application should request the "acr" claim as an
"essential" claim. A straightforward way is to embed
"acr":{"essential":true,"values":[...]} in the "claims" request parameter
(OIDC Core Section 5.5). (NOTE: the "acr_values" request parameter and the
"default_acr_values" client metadata cannot request claims as essential.)

The draft of OAuth 2.0 Step-up Authentication Challenge Protocol recommends
that ACRs requested by the "acr_values" request parameter be treated as
required (= essential). The recommendation may be okay, but it should be
better for the specification to mention additionally that there is a
standardized way to request the "acr" claim as essential. That is, it is
better to introduce "acr":{"essential":true,"values":[...]} somewhere in
the specification.

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

Re: [OAUTH-WG] RFC 8705: How do we get client certificate from mTLS stack to OAuth stack for thumbprint confirmation

[Takahiko Kawasaki]

Dear Jaimandeep,

Regarding the first question.

If the token endpoint of an authorization server and protected resource
endpoints of a resource server directly communicate with client
applications, meaning that there is no reverse proxy in between the
endpoints and client applications, the endpoints must be able to extract a
client certificate directly from a mutual TLS connection.

On the other hand, if a reverse proxy sits in between the endpoints and
client applications, the reverse proxy must be able to extract a client
certificate from a mutual TLS connection and pass it to the endpoints
behind the reverse proxy. In turn, the endpoints must be able to receive a
client certificate from the reverse proxy. How a reverse proxy passes a
client certificate to the backend server depends on implementations.

In both patterns, details vary depending on implementations of web
frameworks and reverse proxies / API gateways. In the first pattern, for
example, in Java's Servlet API, endpoints can extract a client certificate
by calling
HttpServletRequest.getAttribute("javax.servlet.request.X509Certificate").
In the second pattern, X-Ssl-Cert and X-Ssl-Cert-Chain-* HTTP headers are
often used to convey a client certificate chain from a reverse proxy to a
backend server, but the HTTP headers are not standardized ones. There
exists a proposed standard that defines Client-Cert and Client-Cert-Chain
HTTP headers for the purpose (
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-cert-field/ ).
Cloud-based API gateway solutions often take their own approaches. For
example, in Amazon API Gateway, a Lambda function can extract a client
certificate from
event['requestContext']['authentication']['clientCert']['clientCertPem'] (
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-input.html
).

As listed above, there are a variety of ways to extract a client
certificate from a mutual TLS connection and pass it to endpoints. So, it
might not be appropriate to list implementation-specific examples in the
specification.

If you are interested in real examples, please read an online document
below where you can find "NGINX" and "Amazon API Gateway" examples.

Financial-grade Amazon API Gateway
https://www.authlete.com/developers/tutorial/financial_grade_apigateway/

Regarding the second question.

A resource server does not have to publish its public keys via "jwks_uri",
"jwks" or something equivalent unless the resource server wants the
authorization server to encrypt access tokens with an "asymmetric"
algorithm (where the resource server must hold a "private" key to decrypt
access tokens and the authorization server uses the corresponding "public"
key to encrypt access tokens).

PKI has already established a solid method to validate a certificate chain,
so there is little need to publish public keys for verifying certificate
signatures via "jwks_uri" or "jwks".

Best Regards,
Takahiko Kawasaki


On Tue, Aug 16, 2022 at 3:57 PM Jaimandeep Singh  wrote:

> Hi All,
>
> 1. RFC 8705, requires thumbprint confirmation of the client certificate.
> It is the same client certificate which is used by client application while
> establishing mutual-TLS with the authorisation server or the protected
> resource server. I have not found any specific methodology in the RFC to
> get this client certificate from the mTLS stack to the OAuth stack for
> enabling thumbprint confirmation. Section 3.2 of RFC 8705 states:
>
> The protected resource compares that certificate hash to a hash of the
> client certificate used for mutual-TLS authentication and rejects the
> request if they do not match.
>
>
>
> 2. The RFC 8705 has provision of associating client certificate metadata
> in the form of 'jwks_uri' or 'jwks' with the authorisation server. Section
> 2.2.2. states
>
>> For the Self-Signed Certificate method of binding a certificate with a
>> client using mutual-TLS client authentication, the existing jwks_uri or
>> jwks metadata parameters from [RFC7591] are used to convey the client's
>> certificates via JSON Web Key (JWK) in a JWK Set [RFC7517].
>
> However, the RFC does not spell out any association of 'jwks_uri' or
> 'jwks' with protected resource servers. Also, as per RFC 7517  'jwks_uri'
> or 'jwks' is used at application level mostly to validate the signatures of
> the signed tokens. Is there any update in RFC for TLS to use 'jwks_uri' or
> 'jwks' as keystores for the client certificates in TLS based authentication
> mechanism? Section 2 of RFC 7517 states:
>
>> For instance, these keys might be used by some applications for
>> validating si

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

[Takahiko Kawasaki]

Dear Hannes,

For the writeup:
Authlete supports RAR since version 2.2 and it is confirmed that at least
one of their customers is operating a commercial service that utilizes RAR
with CIBA as of April, 2022.

Best Regards,
Takahiko Kawasaki


On Wed, Apr 6, 2022 at 10:46 PM 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
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Listing OAuth Access Token Metadata

[Takahiko Kawasaki]

Dear Dhaura,

My recommendation to you (undergraduate? LinkedIn says so) is to
investigate the following as the first step.


   - ID Token (OpenID Connect Core 1.0, Section 2)
   - UserInfo Endpoint (OpenID Connect Core 1.0, Section 5.3)


In general, inventing a new grant type should be the last resort.

Best Regards,
Takahiko Kawasaki


On Sun, Apr 3, 2022 at 3:35 PM David Waite  wrote:

>
> On Apr 1, 2022, at 3:24 AM, Dhaura Pathirana 
> wrote:
>
> I would like to know if anyone has seen this (listing token metadata) as a
> common use case in OAuth2 and a standard way of doing it had been proposed
> before?
>
>
> OAuth Token Introspection (RFC 7662) defines a way to query for active
> state and meta-info.
>
> However, its use is defined only for protected resources, and not the
> resource owner or the client the token was issued to.
>
> -DW
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and OAuth 2.1

[Takahiko Kawasaki]

Allowing to specify the same authorization code for retrial due to network
failure is different from allowing reuse of successfully-consumed
authorization code. They should not be mixed. The former is acceptable, but
the latter should be prohibited.


The difference between (1) reuse of authorization code and (2) reuse of
successfully-consumed authorization code is important for discussion.


Taka

On Sat, Oct 16, 2021 at 12:13 AM Daniel Fett  wrote:

> I don't think that a MAY is appropriate here.
>
> I wasn't in the call yesterday, so I hope I don't miss anything here,
> but...
>
> Even with PKCE, the one-time use requirement of the code is still
> important. First and foremost, if we allow unlimited re-use of the same
> code, even just as an option, we change the semantics of this artifact. I
> guess there are many examples where this causes issues, but one would be
> DPoP. It assumes that there is only one (successful) token request and in
> that request, the token is bound to a specific key. If there can be more
> than one successful token request, all it takes is code_challenge and the
> code sitting around somewhere in accessible memory and an XSS attacker can
> exfiltrate them and use them on his own device, binding the resulting token
> to an attacker-controlled key. This is the attack outcome against which we
> introduced the nonce in DPoP. (Probably we should add this thought as a
> security consideration to DPoP, but that is a different topic.) I guess we
> can come up with many other mechanisms and mitigations that depend on code
> being one-time use.
>
> The attack described also shows nicely that code replay protection and
> PKCE serve similar purposes, but are not the same thing.
>
> The Security BCP introduces a second layer of defense at pretty much all
> the critical places in the protocol, because practice shows that a single
> defense can break too easily. For example, an attacker with read-only
> access to the token request would be pretty bad without code replay
> protections in place. Such attackers are considered in FAPI. (Somebody
> capable of reading system logs at the client or server, proxy logs at the
> client or server, browser logs, etc.)
>
> Therefore, in my opinion, the code MUST be short-lived and at least
> SHOULD, better MUST be one-time use.
>
> And ideally, the code SHOULD also be invalidated if the PKCE verifier does
> not match, not sure if that is in the current text or not.
>
> -Daniel
>
>
>
> Am 15.10.21 um 11:04 schrieb Pieter Kasselman:
>
> SHOULD is more likely to cause the right conversations to take place for
> implementors as they weigh the risks. Reducing it to MAY risks diluting it
> too much.
>
>
>
> *From:* OAuth   *On
> Behalf Of *Warren Parad
> *Sent:* Friday 15 October 2021 09:25
> *To:* Pieter Kasselman 
> 
> *Cc:* IETF oauth WG  
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> I wouldn't be against lowering it to MAY but only if we stipulate a SHOULD
> on an expected lifetime of an authorization code. I think sending the
> message that these should be one time use except in exceptional
> circumstances.
>
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> 
> .
>
>
>
>
>
> On Fri, Oct 15, 2021 at 10:17 AM Pieter Kasselman  40microsoft@dmarc.ietf.org> wrote:
>
> Any weakening of the requirement should include a clear outline of the
> risks to help implementors make informed decisions.
>
>
>
> *From:* OAuth  *On Behalf Of *Ash Narayanan
> *Sent:* Friday 15 October 2021 01:51
> *To:* Aaron Parecki 
> *Cc:* IETF oauth WG 
> *Subject:* Re: [OAUTH-WG] [EXTERNAL] Re: Authorization code reuse and
> OAuth 2.1
>
>
>
> You don't often get email from ashvinnaraya...@gmail.com. Learn why this
> is important 
>
> Yes, as I said before, authorization servers are free to enforce one-time
> use of the authorization code even if there isn't a requirement to. The
> proposal is just to remove the *requirement* of authorization servers
> enforcing it.
>
>
>
> I agree, and therefore I think what it really ought to be is "MAY".
>
>
>
> Annabelle said:
>
> There are legitimate use cases for a client to replay an authorization
> code. Connection failures happen. Servers fall over before completing
> requests. Users hit browser refresh buttons. Permitting replay of
> authorization codes (assuming valid PKCE, client creds, etc.) allows
> clients to handle these failure modes simply and gracefully via retries.
>
>
>
> Couldn't agree

Re: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification

[Takahiko Kawasaki]

Authlete supports the specification from version 2.2.2 (2021-Feb-12)
onwards.

Authlete 2.2.2 Release Notes / OAuth 2.0 Authorization Server Issuer
Identifier in Authorization Response
https://www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorization-server-issuer-identifier-in-authorization-response

Also, I mentioned the "iss" response parameter in a certain monthly
magazine for software engineers which will be published in Japan soon.

Best Regards,
Takahiko Kawasaki

On Sun, Sep 5, 2021 at 11:50 PM Dominick Baier 
wrote:

> We have implemented it
>
> https://duendesoftware.com/products/identityserver
>
> ———
> Dominick Baier
>
> On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef (
> rifaat.s.i...@gmail.com) wrote:
>
> All,
>
> As part of the shepherd write-up for the OAuth 2.0 Authorization Server
> Issuer Identification document, we need a list of implementations for this
> specification.
>
> Please, reply to this email on the list with any
> implementation details for this document.
>
> Regards,
>  Rifaat
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

Hi Karsten,

I've read the specification and implemented it. I think that the
specification is good enough for implementers. Actually, the latest version
of my company's product supports the specification and has already been
rolled out. The release note of the version mentions the specification. If
you are interested, please visit the page:

https://www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorization-server-issuer-identifier-in-authorization-response

Best Regards,
Takahiko Kawasaki


On Wed, May 19, 2021 at 3:45 PM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> 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 
> 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 <
>> 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
>>> 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

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

[Takahiko Kawasaki]

Hello Hannes,

Authlete supports PAR and has passed the PAR test cases in the OpenID
conformance suite.

Documents mentioning Authlete's PAR support:
https://www.authlete.com/news/20210204_authlete_2_2/
https://www.authlete.com/developers/relnotes/2.2/

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Thu, Mar 25, 2021 at 4:53 AM 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth WG Virtual Office Hours is cancelled this week

[Takahiko Kawasaki]

What is blocking the progress? I hope the writeup is written soon, too. The
following are some facts around PAR, FYI.


   - The specification of PAR (OAuth 2.0 Pushed Authorization Requests) is
   stable.
   - The OpenID conformance suite has already implemented test cases for
   PAR.
   - There exist some authorization server implementations that support PAR.
   - Australian CDR (Consumer Data Right) has adopted PAR.
   - PAR is listed as a component of FAPI (Financial-grade API) v2.
   - PAR is mentioned in FAPI v1 Final (which was approved in January 2021).


Taka


On Tue, Mar 9, 2021 at 5:45 AM Brian Campbell  wrote:

> I typically take a couple minutes of the Virtual Office Hours call to
> inquire about the status of the shepherd writeup for the Pushed
> Authorization Requests draft. With the cancellation of the meeting, I guess
> I'll do that here by email instead. Any progress on that front?
>
> The chairs had previously indicated off-list that Hannes would be the
> document shepherd, however, I just noticed that the tracker still says "No
> shepherd assigned" [1].
>
> I do, of course, realize that these things can take some time but this
> document has been lingering for what feels like an unusually long time for
> this stage of the process. WGLC for the draft wrapped up in late August of
> last year [2] and a draft update addressing comments received during last
> call was published in mid-September [3].
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
> [2]
> https://mailarchive.ietf.org/arch/msg/oauth/Ua96pMGP2m_UkO123c2gYzrNvsQ/
> [3]
> https://mailarchive.ietf.org/arch/msg/oauth/qzQcfcpodeWI8fjHy_KjSJ78Lqw/
>
>
>
> On Sun, Mar 7, 2021 at 6:26 AM Rifaat Shekh-Yusef 
> wrote:
>
>> All,
>>
>> Because of the IETF conference, the OAuth WG Virtual Office Hours is
>> Cancelled this week.
>>
>> 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
>
___
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

[Takahiko Kawasaki]

+1. I've implemented the specification. I think that the current draft is
already good enough for implementers. Thank you, authors.

Taka

On Tue, Dec 8, 2020 at 9:50 PM 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
> ___
> 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] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt

[Takahiko Kawasaki]

Hi Karsten,

I read draft-meyerzuselhausen-oauth-iss-auth-resp-02. I think it is good
enough for authorization server implementers to implement the specification.

Best Regards,
Taka

On Tue, Nov 17, 2020 at 8:48 PM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> Hi all,
>
> thank you for your valuable feedback on the last draft version. Daniel and
> I tried to address all comments in the new version.
>
> Changes in -02:
>
>- Incorporated WG feedback
>- Clarifications for unique issuer identifier
>- Clarifications when multiple issuer identifier could be present
>- Added note that iss parameter MUST NOT be used with JARM
>- Added note on error responses and example for error response
>- 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-02.txt
> Date: Tue, 17 Nov 2020 03:42:02 -0800
> From: internet-dra...@ietf.org
> To: Karsten zu Selhausen 
> , Daniel Fett 
> , Karsten Meyer zu Selhausen
> 
> 
>
>
> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
> has been successfully submitted by Karsten Meyer zu Selhausen and posted
> to the
> IETF repository.
>
> Name: draft-meyerzuselhausen-oauth-iss-auth-resp
> Revision: 02
> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization
> Response
> Document date: 2020-11-17
> Group: Individual Submission
> Pages: 10
> URL:
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.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-02.html
> Htmlized:
> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-02
>
> 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
>
> Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth 
> und OpenID Connect am 27.01 + 28.01.2021 
> teil:https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021
>
> 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

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 
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 
> 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 for the `iss` parameter. Therefore, such
>> authorization response does not have to have the `iss` parameter outside
>> the JWT separately. Examples of such JWTs include the value of the
>> `id_token` parameter in OIDC and the value of `response` parameter in JARM.
>>
>> Taka
>>
>> On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan 
>> wrote:
>>
>>> I agree, it is in redundant in the JARM case.
>>>
>>> I find the text in
>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
>>> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
>>> think it would be good to say something along the lines of:
>>>
>>> Although integrity protection is not necessary to prevent mixup, any
>>> authorization response method that includes a JWT with an ‘iss' (for
>>> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
>>> client is validating the iss).
>>>
>>>
>>> I’m not entirely sure I underst

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

[Takahiko Kawasaki]

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  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 for the `iss` parameter. Therefore, such authorization
> response does not have to have the `iss` parameter outside the JWT
> separately. Examples of such JWTs include the value of the `id_token`
> parameter in OIDC and the value of `response` parameter in JARM.
>
> Taka
>
> On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan  wrote:
>
>> I agree, it is in redundant in the JARM case.
>>
>> I find the text in
>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
>> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
>> think it would be good to say something along the lines of:
>>
>> Although integrity protection is not necessary to prevent mixup, any
>> authorization response method that includes a JWT with an ‘iss' (for
>> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
>> client is validating the iss).
>>
>>
>> I’m not entirely sure I understand what "MUST NOT allow multiple
>> authorization servers to return the same issuer identifier during
>> registration” means as I don’t think https://tools.ietf.org/html/rfc7591
>> returns the issuer?
>>
>> It might be clearer to say something like “When
>> https://tools.ietf.org/html/rfc8414 is used the client MUST implement
>> the validation described in
>> https://tools.ietf.org/html/rfc8414#section-3.3. When 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 
>> 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 Kawasak

Re: [OAUTH-WG] oauth par - authorize request with client_id

[Takahiko Kawasaki]

Hi Sascha,

The change you found in the draft 04 is the change made to the JAR (JWT
Secured Authorization Request). Now, "client_id" is mandatory. I summarized
technical details about JAR in the article below. It describes the reasons
for the necessity of "client_id". PAR is mentioned there, too.

Implementer's note about JAR (JWT Secured Authorization Request)
https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe

Best Regards,
Taka

On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch 
wrote:

> Hi all!
>
> A while ago I implemented draft 00 of this spec:
> - https://tools.ietf.org/html/draft-ietf-oauth-par-04
>
> Now, in draft 04, I see that a request to the /authorize endpoint is
> defined with client_id and request_uri. The client_id was added since draft
> 00 (see: https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-4).
>
> I am not sure if 'client_id' is now required, that's all.
>
> Thanks for clarification,
>
> regards,
> Sascha
> ___
> 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] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Takahiko Kawasaki]

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 for the `iss` parameter. Therefore, such authorization
response does not have to have the `iss` parameter outside the JWT
separately. Examples of such JWTs include the value of the `id_token`
parameter in OIDC and the value of `response` parameter in JARM.

Taka

On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan  wrote:

> I agree, it is in redundant in the JARM case.
>
> I find the text in
> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
> (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I
> think it would be good to say something along the lines of:
>
> Although integrity protection is not necessary to prevent mixup, any
> authorization response method that includes a JWT with an ‘iss' (for
> example, JARM or OIDC hybrid flow) will prevent the attack (assuming the
> client is validating the iss).
>
>
> I’m not entirely sure I understand what "MUST NOT allow multiple
> authorization servers to return the same issuer identifier during
> registration” means as I don’t think https://tools.ietf.org/html/rfc7591
> returns the issuer?
>
> It might be clearer to say something like “When
> https://tools.ietf.org/html/rfc8414 is used the client MUST implement the
> validation described in https://tools.ietf.org/html/rfc8414#section-3.3.
> When 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 
> 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}&iss={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 
> 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
>> 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.or

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

[Takahiko Kawasaki]

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}&iss={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 
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
> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [JAR] For future readers and implementers

[Takahiko Kawasaki]

Hello,

As it seems that the community has reached a consensus on how to solve
conflicts between JAR (OAuth 2.0 JWT Secured Authorization Request) and
OIDC Core and that the OpenID conformance suite has been updated
accordingly, I collected scattered pieces of information about JAR for
future readers and implementers of the specification.

Implementer’s note about JAR (JWT Secured Authorization Request)
https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe

Small feedback from me to the draft version 30 is s/"request_uri
parameter"/"request_uri" parameter/ for Section 9.2 and 9.3.

Best Regards,
Taka
___
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

[Takahiko Kawasaki]

"there seems to be a good consensus that servers must not require the
duplicates."

from FAPI Issue 315: PAR certification question - must servers allow
requests where scope/response_type only passed to PAR endpoint
https://bitbucket.org/openid/fapi/issues/315/par-certification-question-must-servers

A consensus has been reached which is enough at least for the conformance
suite. It is the same as my suggestion. Thank you for discussion.

Taka


On Wed, Sep 30, 2020 at 2:21 PM Takahiko Kawasaki  wrote:

> So, my suggestion is "When JAR compatible behaviors are employed, AS
> implementations should not require that an OIDC request come with `scope`
> query/form parameter when the request uses a request object." (NOTE: "an
> OIDC request" implies that the request object contains `scope` including
> `openid`.)
>
> Any thoughts?
>
> Taka
>
> On Thu, Sep 24, 2020 at 11:07 PM Takahiko Kawasaki 
> wrote:
>
>> Hi Vladimir,
>>
>> Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not
>> require all request parameters be put duplicately in a request object. It
>> is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2
>> <https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>
>> Clause 10) that has the requirement. In the context of FAPI Part 1, a
>> request object does not have to be used. One more note is that parameters
>> inside a request object and parameters outside a request object are merged
>> (as they are in OIDC Core 1.0) when the authorization request is being made
>> for FAPI Read-Only APIs (not for FAPI Read-Write APIs).
>>
>> Taka
>>
>>
>> On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov <
>> vladi...@connect2id.com> wrote:
>>
>>> 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
>>

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

[Takahiko Kawasaki]

So, my suggestion is "When JAR compatible behaviors are employed, AS
implementations should not require that an OIDC request come with `scope`
query/form parameter when the request uses a request object." (NOTE: "an
OIDC request" implies that the request object contains `scope` including
`openid`.)

Any thoughts?

Taka

On Thu, Sep 24, 2020 at 11:07 PM Takahiko Kawasaki 
wrote:

> Hi Vladimir,
>
> Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not
> require all request parameters be put duplicately in a request object. It
> is FAPI (version 1) Part 2 (Read-Write) (Section 5.2.2
> <https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>
> Clause 10) that has the requirement. In the context of FAPI Part 1, a
> request object does not have to be used. One more note is that parameters
> inside a request object and parameters outside a request object are merged
> (as they are in OIDC Core 1.0) when the authorization request is being made
> for FAPI Read-Only APIs (not for FAPI Read-Write APIs).
>
> Taka
>
>
> On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> 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 offic

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Takahiko Kawasaki]

>And now for the thorny isssues with this draft. Signatures and encryption
are different. And encrypting a signed blob doesn't mean the signer
encrypted it.

Who encrypts data doesn't matter. Especially, when the encryption algorithm
is asymmetric, anyone who has a "public" key, which anyone can get, can
encrypt data. What matters is who can decrypt the encrypted data. It is
only the party who has the corresponding "private" key that can decrypt the
encrypted data.

Best Regards,
Takahiko Kawasaki

On Sat, Sep 26, 2020 at 9:47 AM Watson Ladd via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Watson Ladd
> Review result: Serious Issues
>
> I generated this review of this document as part of the security
> directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These
> comments were written with the intent of improving security requirements
> and
> considerations in IETF drafts.  Comments not addressed in last call may be
> included in AD reviews during the IESG review.  Document editors and WG
> chairs
> should treat these comments just like any other last call comments.
>
> Two minor issues: On page 4, "This offers an additional degree of privacy
> protection." should be reworded. I don't think it makes sense in context,
> where
> authenticity was discussed.
>
> It took me a while to understand what the by reference method is: maybe the
> intro should say via URL instead of by reference.
>
> And now for the thorny isssues with this draft. Signatures and encryption
> are
> different. And encrypting a signed blob doesn't mean the signer encrypted
> it.
> Then there are a plethora of methods specified in the draft  to
> authenticate
> the blob, which will give different results in maliciously constructed
> examples. The security considerations section should discuss what the
> encrypted
> vs signed choices give in the way of security, and it doesn't. This makes
> me
> worry.
>
> Looking at the cited reference for attacks, I see the fix is to include
> information about which IPD was used by the RP. But the draft before us
> doesn't
> mandate that. It's not clear than how the cited attack is prevented by the
> draft. Saying that the communication through the user-agent is subject to
> manipulation, and this prevents it, ignores that the attacker in that
> position
> sees a lot more. The user-agent as resource owner modifying the requested
> resources is a very funny sort of attack: can't they do what they want
> with the
> resources since they control the access?
>
> Key management is ignored. This is a very important issue, especially
> considering the potential problems with the reuse of JWT. I'd like to see a
> recommendation that keys be separated by intended uses, rather than
> limiting
> particular fields in an ad-hoc manner.
>
> Then we have section 11. What section 11 introduces is an entire new
> dramatis
> personae, the Trust Framework Provider, with no prior discussion of what
> it is
> or a reference to where it is defined and a good number of statements
> about how
> it works that aren't really  clear what they mean from the document to me.
>
> My biggest concern is that these issues are signs that the problem this
> draft
> is trying to solve and the mechanisms to solve it haven't been analyzed as
> thoroughly as they should have been. Without that sort of thorough analysis
> it's not certain that the mechanisms actually solve the problem and it's
> not
> clear what the recommendations to implementors have to be to preserve those
> properties.
>
> Obviously this draft has had a long and tortured history with multiple
> reviews,
>  and what I'm suggesting needs to happen is a lot of work. But it's
> essential
> in any security protocol to do this analysis and be clear about what is,
> and
> what is not, protected by the protocol.
>
> Sincerely,
> Watson Ladd
>
>
> ___
> 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] [JAR] scope parameter outside request object of OIDC request

[Takahiko Kawasaki]

Hi Vladimir,

Just FYI. To be exact, FAPI (version 1) Part 1 (Read-Only) does not require
all request parameters be put duplicately in a request object. It is FAPI
(version 1) Part 2 (Read-Write) (Section 5.2.2
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>
Clause 10) that has the requirement. In the context of FAPI Part 1, a
request object does not have to be used. One more note is that parameters
inside a request object and parameters outside a request object are merged
(as they are in OIDC Core 1.0) when the authorization request is being made
for FAPI Read-Only APIs (not for FAPI Read-Write APIs).

Taka


On Thu, Sep 24, 2020 at 7:14 PM Vladimir Dzhuvinov 
wrote:

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

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

[Takahiko Kawasaki]

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 
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=...&request(_uri)=..."
> fails if the request object represents an OIDC request. An authorization
> request has to look like "client_id=...&request(_uri)=...&scope=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
> Authle

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

[Takahiko Kawasaki]

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=...&request(_uri)=..."
fails if the request object represents an OIDC request. An authorization
request has to look like "client_id=...&request(_uri)=...&scope=openid"
(`scope` including `openid` has to be given) even if the authorization
server conforms to JAR and allows omission of `response_type` request
parameter.

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

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

[Takahiko Kawasaki]

To enable each "instance" of a client application to use a key pair which
is dedicated to the instance, the public key needs to be included in the
DPoP proof. On the other hand, in the scenario you described, all instances
of the client application have to share one key pair. If client application
instances don't have to share one key pair, it's better.

Illustrated DPoP (OAuth Access Token Security Enhancement)
https://medium.com/@darutk/illustrated-dpop-oauth-access-token-security-enhancement-801680d761ff

Best Regards,
Takahiko Kawasaki

On Tue, Sep 8, 2020 at 6:29 PM  wrote:

> Hi all,
>
> In section 4.1 of draft-ietf-oauth-dpop-01, the "jwk" header parameter is
> REQUIRED. However, there are some cases where "jwk" is not necessary in
> theory.
>
> For example, consider a case where the client is registered with the
> Authorization Server, and its one and only public key is also registered
> with
> the AS. In that case, when the AS receives a request on Token endpoint, it
> can
> just use the public key registered for the client to verify the DPoP Proof.
> There is no need to send the public key in DPoP Proof.
>
> The same goes for requests to the Resource Server, if the AS and RS share
> the
> storage for clients' public keys. Things are a little difficult if the AS
> and RS
> are separate. Probably the Access Token or its introspection result have to
> include the public key (instead of its thumbprint as described in section
> 7).
>
> If the client registers multiple keys with the AS, it needs to specify
> which key
> it uses to sign the DPoP Proof. However, there is still no absolute need
> to send
> the whole key in DPoP Proof. Instead, the client could use "kid" header
> parameter to specify the key.
>
> Daniel Fett once mentioned the above case in the GitHub issue #26 [*1],
> but I'm
> not sure what happened to the discussion. There was also a comment on the
> latest
> draft about the "jwk" header parameter [*2]. I agree with using the same
> DPoP
> Proof structure for requests to AS and RS, but I think there are some cases
> where we can omit "jwk" in BOTH requests. Making "jwk" OPTIONAL would allow
> those cases to reduce some messaging overhead.
>
> I'd like to hear your opinions about it.
>
>
> [*1]:
> https://github.com/danielfett/draft-dpop/issues/26#issuecomment-480701746
> [*2]:
> https://mailarchive.ietf.org/arch/msg/oauth/smwsONA6c4H2UICcZMzb8Yv2QRc/
>
>
> Best regards,
> Toshio Ito
>
> -
> Toshio Ito
> Research and Development Center
> Toshiba Corporation
>
> ___
> 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 Review of PAR

[Takahiko Kawasaki]

Under existing specifications (RFC 6749, OIDC Core 1.0 and FAPI), a client
can choose an arbitrary redirect_uri without registering it only when all
the following conditions are satisfied.

1. The client type of the client is "confidential". (RFC 6749 Section
3.1.2.2 requires that public clients register redirect URIs.)
2. The flow is not "implicit". (RFC 6749 Section 3.1.2.2 requires that
confidential clients utilizing the implicit grant type register redirect
URIs.)
3. The authorization request is not an OIDC request. (OIDC Core 1.0 Section
3.1.2.1 requires that redirect_uri match a pre-registered one.)
4. The authorization request is not a FAPI request. (FAPI Part 1 Section
5.2.2 Clause 8 requires that redirect URIs be pre-registered.)

In short, under existing specifications, pure RFC-6749
authorization-code-flow requests from confidential clients can choose an
arbitrary redirect_uri without registering it. Once OIDC or FAPI is used,
existing specifications require pre-registration of redirect URIs. I'm not
sure but if PAR's "redirect_uri Management" is going to introduce rules
that conflict with existing specifications, it is better to list the
conflicts explicitly in the section.

Best Regards,
Takahiko Kawasaki


On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt  wrote:

> Here is my proposal for the new section:
>
> 2.4. redirect_uri Management
>
> The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth
> 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri
> parameter against the set of redirect URIs previously established for a
> particular client. This is a means to early detect attempts to impersonate
> a client and prevent token leakage and open redirection. As a downside, it
> makes client management more complex since the redirect URI is typically
> the most volatile part of a client policy.
>
> This requirement MAY be relaxed by the AS, if a confidential client uses
> pushed authorization requests since the AS authenticates the client before
> the authorization process starts and that way ensures it interacts with the
> legit client. The AS MAY allow such clients to specify redirect_uri values
> not previously registered with the AS. This will give the client more
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes
> client management much easier. It is at the discretion of the AS to apply
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI
> prefix or allow only a query parameter to vary at runtime.
>
> Note: The aibility to set up transaction specific redirect URIs is also
> useful in situations where client ids and correspoding credentials and
> policies are managed by a trusted 3rd party, e.g. via client certifiates
> containing client permissions. Such an externally managed client could
> interact with an AS trusting the respective 3rd party without the need for
> an additional registration step.
>
> > On 29. Aug 2020, at 17:22, Justin Richer  wrote:
> >
> > I completely agree with the utility of the function in question here and
> it needs to be included. I’m in favor of creating a dedicated section for
> redirect_uri management, so that we can explain exactly how and why to
> relax the requirement from core OAuth. In addition, I think we want to
> discuss that the AS might have its own restrictions on which redirect URIs
> an authenticated client might be able to use. For example, registering a
> client with a Redirect URI prefix, or allowing only a query parameter to
> vary at runtime. All of these can be enforced in PAR because the client is
> presenting its authentication, as you point out, so the AS can determine
> which policies should apply.
> >
> > — Justin
> >
> >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> >>
> >>
> >>>
> >>>
> >>>   ¶6: Does the AS really have "the ability to authenticate and
> authorize clients”? I think what we mean here is "the ability to
> authenticate clients and validate client requests”, but I’m not positive of
> the intent.
> >>>
> >>> I think the intent is that the AS can check whether a client is
> authorized to make a particular authorization request (specific scopes,
> response type, etc.). But checking authorization to request authorization
> is confusing wording. I think your working is less confusing and still
> allows for the intent.
> >>>
> >>> I'll let Torsten interject if he feels differently as I think he
> originally wrote the text in question.
> >>
> >> that was the original intent. I think “validate" is fine.
> >>
> >

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

[Takahiko Kawasaki]

に不自然な点が多いし裏事情がはっきりした今となっては黙っている訳にもいかないので、メーリングリストで意見を述べた。
>
>
>
> https://mailarchive.ietf.org/arch/msg/oauth/Jy1fpar6LKnNX_zpoT7_fpCzBSg/
>
> I've heard rumors that the JWT Access Token standard specification work
> was started to get the industry to accept the current implementation of
> Auth0, but was that really the case? Since there are many technical
> unnatural points and it is impossible to keep silent now that the
> circumstances are clear, I made an opinion on the mailing list.
>
>
>
> ついでに言っておくと、Auth0 が生成する JWT アクセストークンの署名アルゴリズムとして選択できるのは、HS256 と RS256
> のみのようだ。HS256 は対称鍵系アルゴリズム。一方の RS256 は非対称鍵系アルゴリズムだが、セキュリティー上の理由で
> Financial-grade API Part 2 では使用禁止とされている。
>
> Incidentally, it seems that only HS256 and RS256 can be selected as the
> signature algorithm for the JWT access token generated by Auth0. HS256 is a
> symmetric key algorithm. On the other hand, RS256 is an asymmetric key
> algorithm, but for security reasons, it is prohibited in Financial-grade
> API Part 2.
>
>
>
>
>
> *From: *OAuth  on behalf of Takahiko Kawasaki <
> t...@authlete.com>
> *Date: *Thursday, April 23, 2020 at 18:01
> *To: *oauth 
> *Cc: *Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> I apologize if my previous post has made you all here feel unpleasant,
> especially I'm sorry for the author, the chairs, and people who directly
> joined the discussion about the spec. I could have expressed my
> disagreement on the requirements for "aud" and "sub" in another different
> way. For software specifications and architectures, I'm liable to get
> excited and aggressive. Please forgive me.
>
> Regarding the relationship between "aud" and "scope", the assumption in
> the draft is not necessarily applicable to all possible use cases. For
> example, multiple resources may share the same scopes. What if both
> "/resource1" and "/resource2" recognize "get" scope and "update" scope? In
> this case, it is not appropriate to determine the default resource
> indicator for "aud" from the scopes. It is also impossible to map scopes to
> resources and vice versa. The assumption in the current draft is too narrow
> to be included in a standard.. If the current description continues to
> exist, it will impose big restrictions on the design of scopes and
> resources.
>
> If you still think the "aud" claim should always exist, then the
> authorization endpoint and/or the token endpoint (and/or the backchannel
> authentication endpoint and/or the device authorization endpoint) of your
> system can require the "resource" request parameter as mandatory. We don't
> have to put rules to determine the default "aud" value into the spec about
> JWT access tokens. The "resource" parameter defined in RFC 8707 can work
> regardless of whether the format of access tokens is JWT or not. Therefore,
> it is not appropriate to discuss the necessity of the "aud" claim only in
> the context of "JWT" access tokens.
>
> Regarding the "sub" claim, setting the client ID there, rather, will
> confuse resource servers. If the "sub" claim is set even in the case of the
> client credentials flow, resource servers cannot judge whether the "sub"
> claim represents either the subject of the resource owner or the client ID.
> On the other hand, if the "sub" claim is null or absent in the case of the
> client credentials flow, resource servers can always handle the value of
> the "sub" claim as the subject of the resource owner. For resource servers,
> this logic is easier. Setting the "sub" claim in every case to make
> resource server implementations simpler is not convincing.
>
> Best Regards,
> Taka
>
>
>
> On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki 
> wrote:
>
> First, to make the discussion fair, I think I should share what I observed
> today. Auth0's client_credentials flow requires an "audience" parameter,
> which is equivalent to the "resource" parameter defined in RFC 8707, and
> embeds the client ID in the generated JWT access token as the value of the
> "sub" claim.
>
> My opinion as a software engineer is as follows.
>
> [aud]
> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> inflexible rules to determine the default value for the "aud" claim based
> on the "scope" parameter.
&g

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

[Takahiko Kawasaki]

I apologize if my previous post has made you all here feel unpleasant,
especially I'm sorry for the author, the chairs, and people who directly
joined the discussion about the spec. I could have expressed my
disagreement on the requirements for "aud" and "sub" in another different
way. For software specifications and architectures, I'm liable to get
excited and aggressive. Please forgive me.

Regarding the relationship between "aud" and "scope", the assumption in the
draft is not necessarily applicable to all possible use cases. For example,
multiple resources may share the same scopes. What if both "/resource1" and
"/resource2" recognize "get" scope and "update" scope? In this case, it is
not appropriate to determine the default resource indicator for "aud" from
the scopes. It is also impossible to map scopes to resources and vice
versa. The assumption in the current draft is too narrow to be included in
a standard. If the current description continues to exist, it will impose
big restrictions on the design of scopes and resources.

If you still think the "aud" claim should always exist, then the
authorization endpoint and/or the token endpoint (and/or the backchannel
authentication endpoint and/or the device authorization endpoint) of your
system can require the "resource" request parameter as mandatory. We don't
have to put rules to determine the default "aud" value into the spec about
JWT access tokens. The "resource" parameter defined in RFC 8707 can work
regardless of whether the format of access tokens is JWT or not. Therefore,
it is not appropriate to discuss the necessity of the "aud" claim only in
the context of "JWT" access tokens.

Regarding the "sub" claim, setting the client ID there, rather, will
confuse resource servers. If the "sub" claim is set even in the case of the
client credentials flow, resource servers cannot judge whether the "sub"
claim represents either the subject of the resource owner or the client ID.
On the other hand, if the "sub" claim is null or absent in the case of the
client credentials flow, resource servers can always handle the value of
the "sub" claim as the subject of the resource owner. For resource servers,
this logic is easier. Setting the "sub" claim in every case to make
resource server implementations simpler is not convincing.

Best Regards,
Taka

On Fri, Apr 24, 2020 at 2:15 AM Takahiko Kawasaki  wrote:

> First, to make the discussion fair, I think I should share what I observed
> today. Auth0's client_credentials flow requires an "audience" parameter,
> which is equivalent to the "resource" parameter defined in RFC 8707, and
> embeds the client ID in the generated JWT access token as the value of the
> "sub" claim.
>
> My opinion as a software engineer is as follows.
>
> [aud]
> The "aud" claim should be null or absent when the "resource" parameters
> are not given in an authorization request. It is not good to introduce
> inflexible rules to determine the default value for the "aud" claim based
> on the "scope" parameter.
>
> [sub]
> The "sub" claim should be null or absent when a resource owner is not
> involved in an authorization request. To be concrete, the "sub" claim
> should be null or absent in the client credentials flow. The spec draft
> says in "5. Security Considerations" as follows.
>
> - - - - - - - - - -
> Authorization servers should prevent scenarios where clients can affect
> the value of the sub claim in ways that could confuse resource servers.
> For example: if the authorization server elects to use the client_id as the
> sub value for access tokens issued client credentials grant, the
> authorization server should prevent clients to register an arbitrary
> client_id value, as this would allow malicious clients to select the sub of
> a high privilege resource owner and confuse any authorization logic on the
> resource server relying on the sub value.  For more details please refer to
> section 4.13 of [OAuth2.Security.BestPractices].
>
> To preventing cross-JWT confusion, authorization servers MUST use a
> distinct identifier as "aud" claim value to uniquely identify access tokens
> issued by the same issuer for distinct resources.
> - - - - - - - - - -
>
> However, the attack vector is brought about merely by introducing the
> following rule defined in "2.2. Data Structure".
>
> - - - - - - - - - -
> In case of access tokens obtained through grants where no resource owner
> is involved, such as the client credentials grant, the value of sub SHOULD
> corresp

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

[Takahiko Kawasaki]

First, to make the discussion fair, I think I should share what I observed
today. Auth0's client_credentials flow requires an "audience" parameter,
which is equivalent to the "resource" parameter defined in RFC 8707, and
embeds the client ID in the generated JWT access token as the value of the
"sub" claim.

My opinion as a software engineer is as follows.

[aud]
The "aud" claim should be null or absent when the "resource" parameters are
not given in an authorization request. It is not good to introduce
inflexible rules to determine the default value for the "aud" claim based
on the "scope" parameter.

[sub]
The "sub" claim should be null or absent when a resource owner is not
involved in an authorization request. To be concrete, the "sub" claim
should be null or absent in the client credentials flow. The spec draft
says in "5. Security Considerations" as follows.

- - - - - - - - - -
Authorization servers should prevent scenarios where clients can affect the
value of the sub claim in ways that could confuse resource servers.  For
example: if the authorization server elects to use the client_id as the sub
value for access tokens issued client credentials grant, the authorization
server should prevent clients to register an arbitrary client_id value, as
this would allow malicious clients to select the sub of a high privilege
resource owner and confuse any authorization logic on the resource server
relying on the sub value.  For more details please refer to section 4.13 of
[OAuth2.Security.BestPractices].

To preventing cross-JWT confusion, authorization servers MUST use a
distinct identifier as "aud" claim value to uniquely identify access tokens
issued by the same issuer for distinct resources.
- - - - - - - - - -

However, the attack vector is brought about merely by introducing the
following rule defined in "2.2. Data Structure".

- - - - - - - - - -
In case of access tokens obtained through grants where no resource owner is
involved, such as the client credentials grant, the value of sub SHOULD
correspond to an identifier the authorization server uses to indicate the
client application.
- - - - - - - - - -

If the rule is not introduced, the attack vector disappears and the "aud"
claim doesn't have to be mandatory.

Finally, to make the discussion fair, I should also mention that I myself
is a co-founder of Authlete, Inc. that provides an implementation of OAuth
and OpenID Connect. My thoughts about implementations of access tokens are
publicly described here:

OAuth Access Token Implementation
https://medium.com/@darutk/oauth-access-token-implementation-30c2e8b90ff0

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Wed, Apr 22, 2020 at 4:19 AM Vittorio Bertocci  wrote:

> Ouch! Sorry 😊 fixed
>
>
>
> *From: *Dominick Baier 
> *Date: *Tuesday, April 21, 2020 at 10:23
> *To: *oauth , Rifaat Shekh-Yusef ,
> Vittorio Bertocci 
> *Subject: *Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> Oh and while we are at it - could you also fix the typo in my name? Thanks
> ;)
>
>
>
> ———
>
> Dominick Baier
>
>
>
> On 21. April 2020 at 09:43:49, Vittorio Bertocci (
> vittorio.berto...@auth0.com) wrote:
>
> This is a great point. In my head I just considered the OIDC semantic and
> thought only of highlighting the app identity case, but you are absolutely
> right that not mentioning the user case at all is confusing. I added the
> language you suggested at the beginning of the sub definition.
>
> Thanks!
>
>
>
> *From: *Dominick Baier 
> *Date: *Monday, April 20, 2020 at 22:54
> *To: *oauth , Rifaat Shekh-Yusef ,
> "vittorio.berto...@auth0.com" 
> *Subject: *RE: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens"
>
>
>
> In case of access tokens obtained through grants where no resource owner is 
> involved, such as the client credentials grant, the value of sub SHOULD 
> correspond to an identifier the authorization server uses to indicate the 
> client application.
>
>
>
> Maybe I am missing something, but does it say anywhere what to explicitly
> do in the case of an access token where a resource owner is involved?
>
>
>
> There’s some language that seems to imply that, e.g.:
>
>
>
> as this would allow malicious
>
>clients to select the sub of a high privilege resource owner
>
> I would have expected to see something stronger like above just -
>
>
>
> In case of access tokens obtained through grants where a resource owner is 
> involved, such as the authorisation code grant, the value of sub SHOULD 
> correspond to the subject identifier of the

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

[Takahiko Kawasaki]

(1)
The requirement in the paragraph below excerpted from "3. Requesting a JWT
Access Token":

*If it receives a request for an access token containing more than one
resource parameter, an authorization server issuing JWT access tokens MUST
reject the request and fail with "invalid_request" as described in section
4.1.2.1 of [RFC6749] or with "invalid_target" as defined in section 2 of
[RFC8707].  See Section 2.2 and Section 5 for more details on how this
measure ensures there's no confusion on to what resource the access token
granted scopes apply.*


apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
8707 won't support this draft unless the requirement is loosened, for
example from MUST to SHOULD.

(2)
Regarding another paragraph shown below from the same section.

*If the request does not include a resource parameter, the authorization
server MUST use in the aud claim a default resource indicator.  If a scope
parameter is present in the request, the authorization server SHOULD use it
to infer the value of the default resource indicator to be used in the aud
claim.  The mechanism through which scopes are associated to default
resource indicator values is outside the scope of this specification.  If
the values in the scope parameter refer to different default resource
indicator values, the authorization server SHOULD reject the request with
invalid_scope as described in section 4.1.2.1 of [RFC6749].*


The rule described here whereby to determine the default value of the "aud"
claim is unintelligible. In addition, I don't think the rule referring to
the "scope" parameter is worth being defined. That "aud" is missing but
"scope" is available is enough for resource servers. In other words, if
"aud" is determined based on the "scope", why do we have to set "aud"
redundantly?

Requiring the "aud" as a MUST claim is the reason that this draft has to
introduce philosophy about "aud" that may conflict with other
specifications and may not be supported by all implementers. I would
suggest changing "REQUIRED" to "OPTIONAL".


Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou  wrote:

> Hi all,
>
>
>
> Allow me some comments and forgive me if some of them are naïve.
>
> - In Section 2.2 why nbf claim (
> https://tools..ietf.org/html/rfc7519#section-4.1.5)
> <https://tools.ietf.org/html/rfc7519#section-4.1.5)> is not considered? I
> can imagine some interesting applications of this claim.
>
> - In the same section, it is not clear why some claims are required,
> especially exp, sub, and client_id. The last two claims are not even used
> during token validation.
>
> - RFC7519 specifies that, in the general case, the aud claim is an array
> of StringOrURI values. In this draft it is not clear if this still the
> case, or here aud is a simple string (e.g., in page 5 it is stated: the
> resource indicated in the aud claim, rather than the resource*s*).
>
> - In the token validation procedure, i.e., Section 4, is there any reason
> why the resource server first checks the aud claim, then the signature, and
> finally the exp claim? Given the fact that Error responses are not
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.
>
> - IMHO The token validation procedure it too bound to the particular
> discovery mechanisms mentioned at the beginning of this section. E.g., Step
> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
> Identifier” which must much the iss claim. Moreover, I think it should be
> explicitly mentioned that the resource server “must validate that the JWT
> access token has been singed with a signing key that corresponds to the
> authorization server included in the iss claim”
>
>
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* OAuth  *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, March 23, 2020 11:18 PM
> *To:* oauth 
> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
> Access Tokens"
>
>
>
> Hi all,
>
>
>
> this is a working group last call for "JSON Web Token (JWT) Profile for
> OAuth 2.0 Access Tokens".
>
>
>
> Here is the document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04
>
>
>
> Please send you comments to the OAuth mailing list by April 6, 2020.
>
>
>
> Ciao
>
> Hannes & Rifaat
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

Regarding the name of the JSON property in the payload of the introspection
response JWT.

If we choose a more generic name (e.g. "content") than "token_data", the
approach discussed here can be used as a generic way to wrap a JSON
response in JWT. If we are ambitious, we can even add "content_type".

Example 1:
{
  "iss": "...",
  "content_type": "application/json",
  "content": {
"key0": "value0",
"key1": "value1"
  }
}

Example 2:
{
  "iss": "...",
  "content_type": "application/x-www-form-urlencoded",
  "content": "key0=value0&key1=value1"
}

Taka


On Thu, Mar 5, 2020 at 3:28 AM Torsten Lodderstedt 
wrote:

>
>
> Am 04.03.2020 um 19:18 schrieb Filip Skokan :
>
> 
> Sorry, i meant - is top level jti required as well?
>
>
> I don’t see any use case for it, but that might be due to lack of
> creativity :-)
>
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 4 Mar 2020 at 19:15, Filip Skokan  wrote:
>
>> Torsten, let's make sure we call out the required top level JWT claims -
>> iss, iat, aud, what else? is top level iat required as well?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Wed, 4 Mar 2020 at 17:19, Torsten Lodderstedt 
>> wrote:
>>
>>> Hi all,
>>>
>>> based on the recent feedback, Vladimir and I propose the following
>>> changes to draft-ietf-oauth-jwt-introspection-response:
>>>
>>> - the token data are encapsulated in a container element “_token_data”
>>> - beyond this, the top-level container only contains meta data pertinent
>>> to the JWT representing the signed (encrypted) introspection response
>>> - we need to add text to the spec to point out that replay detection
>>> must be based on the jti in the “_token_data” container not the top level
>>> claim
>>>
>>> That’s example of how it would look like:
>>>
>>> {
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"iat":1532452100,
>>>"_token_data":{
>>>   "active":true,
>>>   "iss":"https://as.example-bank.com";,
>>>   "aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>   "jti":"53304e8a-a81e-4bc7-95e3-3b298d283512",
>>>   "iat":1532452084,
>>>   "exp":1532453100,
>>>   "client_id":"3630BF72-E979-477A-A8FF-8A338F07C852",
>>>   "cnf":{
>>>  "x5t#S256":"YzEcNvUV3QXA5Bi9IB66b8psyqZBQgW4500ZGvNRdis"
>>>   },
>>>   "sub":"123456789087632345678"
>>>}
>>> }
>>>
>>> The response for inactive tokens would look like this:
>>>
>>> {
>>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-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  wrote:
>>> >
>>> > +1, this encapsulation is much cleaner.
>>> >
>>> >> On Mar 2, 2020, at 2:25 AM, Filip Skokan  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 
>>> 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, tho

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

[Takahiko Kawasaki]

Do you mean different requests should have the same jti value for better
security?

It is not good that RFC 7662 has chosen "jti" as a property to hold the
identifier for an access/refresh token although the format of introspection
responses is not JWT but just JSON. If the name were, for instance,
"token_id" or something similar, the problem we are discussing now would
not happen.

Because "jti" has a special meaning in JWT and
draft-ietf-oauth-jwt-introspection-response tries to return introspection
responses in JWT format, the problem occurs.

Not only "jti" but also other properties defined in RFC 7662 that have
special meanings in JWT (that is, "jti", "exp", "iat", "nbf", "sub", "aud"
and "iss") may have problems, too. The namespaces should be separated as
you suggested "underlying_access_token", but because not only access tokens
but also refresh tokens may be passed to the introspection endpoint, a
better name should be chosen.

Taka



On Tue, Mar 3, 2020 at 1:55 AM Torsten Lodderstedt 
wrote:

>
>
> > Am 02.03.2020 um 17:52 schrieb Takahiko Kawasaki :
> >
> > The requirement for "jti" described
> > in draft-ietf-oauth-jwt-introspection-response-08 is problematic.
>
> I think having different jti values for different requests is a security
> risk.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

>From RFC 7662, Section 2.1

*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] or a separate OAuth 2.0
access token such as the bearer token described in OAuth 2.0 Bearer Token
Usage [RFC6750].  The methods of managing and validating these
authentication credentials are out of scope of this specification.*


"Some form of authorization" may not be able to distinguish API callers.
For example, if one pair of API key and API secret is shared by multiple
resource servers.

Even if the number of "resource" request parameters is one, its value is
not necessarily the identifier of a resource server. What if "
https://rs.example.com/resource1"; is given as "resource"? Which value
should "aud" hold, "https://rs.example.com/resource1"; or "
https://rs.example.com";?

If the format of access tokens is JWT, when an authorization request
includes "resource=https://host1.example.com/resource1"; and "resource=
https://host2.example.com/resource2";, the resultant access token will have
"aud" like below.

"aud" : [
  "https://host1.example.com/resource1";,
  "https://host2.example.com/resource2";
]

However, if your logic applies, the introspection response for the access
token will include a different value for "aud". This behavior is confusing.
Because "some form of authorization" is performed when an introspection
call is made, I don't think it's necessary to modify the value of "aud" per
API caller.

Anyway, the root cause is that (a) "aud" in RFC 8707 and (b) "aud"
in draft-ietf-oauth-jwt-introspection-response (in general "aud" in JWT)
are different concepts but they share the same name. Any workaround without
solving the root cause will bring about unhappy future.

Taka


On Tue, Mar 3, 2020 at 1:44 AM Torsten Lodderstedt 
wrote:

> Hi Taka,
>
> I see, the audience is multi value. In my impression both specs assume a
> single value audience.
>
> But I think we can handle this as follows: Since the caller of the
> introspection respect is a single RS, the AS first needs to map & check the
> resources associated with the underlying access token against that caller..
> The RS is authenticated at the introspection endpoint using a client_id
> (and some credential), so the AS needs to map the client_id to resource
> identifier. If the result is in the set of the resources associated with
> the underlying access token, the AS can create an Introspection Response,
> which only contains this particular resource.
>
> What do you think?
>
> best regards,
> Torsten.
>
> > On 2. Mar 2020, at 17:31, Takahiko Kawasaki  wrote:
> >
> > Hi Torsten,
> >
> > For example, if an authorization request includes two "resource" request
> parameters like below,
> >
> > resource=https://host1.example.com/resource1
> > resource=https://host2.example.com/resource2
> >
> > RFC 8707 expects that the value of "aud" in an introspection response
> look like the following.
> >
> > "aud" : [
> >   "https://host1.example.com/resource1";,
> >   "https://host2.example.com/resource2";,
> > ]
> >
> > How does the implementation of the introspection endpoint insert the
> identifier of the resource server (the API caller?) into the "aud" array
> above? In other words, what is the expected resultant value of the "aud"
> array in this case?
> >
> > Taka
> >
> >
> > On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> > Hi Taka,
> >
> > > On 1. Mar 2020, at 08:10, 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 8707 states
> >
> > The authorization server may use
> >the exact "resource" value as the audience or it may map from that
> >value to a more general URI or abstract identifier for the given
> >resource.
> &

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

[Takahiko Kawasaki]

Hi Torsten,

draft-ietf-oauth-jwt-introspection-response-08 says as follows.

*The "jti" claim is a unique identifier for the access token passed in the
introspection request.  This identifier MUST be stable for all
introspection calls for a given access token.*


This requirement expects that the second introspection call with the same
access token will receive a response including the same "jti" value
("abc234567") as was included in the first response. That is, the first JWT
(the first introspection response) and the second JWT (the second
introspection response) have the same jti value. This is what Ben pointed
out.

The requirement for "jti" described
in draft-ietf-oauth-jwt-introspection-response-08 is problematic.

Taka


On Mon, Mar 2, 2020 at 11:19 PM Torsten Lodderstedt  wrote:

> Hi Ben,
>
> >>
> >>>
> >>> I don't think the new semantics for "jti" in the introspection response
> >>> are compatible with the RFC 7519 definition.  Specifically, we say that
> >>> "jti" will be tied to the input access token, but 7519 says that "jti"
> >>> has to change when the contents of the JWT change ("MUST be assigned in
> >>> a manner that ensures that there is a negligible probability that the
> >>> same value will be accidentally assigned to a different data object"),
> >>> and we admit at least the possibility of "active" and "iat" changing.
> >>
> >> I think the key word is “accidentally”. This spec causes the AS to
> purposefully issue JWTs with the same “jti” in order to allow replay
> detection with respect to the introspected access token. “iat” is changed
> in order to give the RS an indication and proof when the introspection
> response was minted by the AS.
> >
> > I think "accidentally" is just there to emphasize that there's a risk of
> > accidental collision when using a random string as an identifier, since
> "of
> > course you wouldn't deliberately reuse a token identifier".  This stance
> > seems to supported by "[t]he 'jti' (JWT ID) claim provides a unique
> > identifier for the JWT".  It's really hard for me to read that sentence
> as
> > allowing the use of a single identifier for two different JWT values,
> since
> > it then ceases to be a *unique* identifier.
> >
> > I seem to have forgotten how this replay detection is supposed to work;
> > would you mind giving me a pointer and/or refresher?
>
> Sure.
>
> 1) Let’s assume a client obtains access token “123456789”, which obviously
> is a handle the RS needs to resolve using Introspection.
> 2) The RS calls the introspection endpoint, the AS looks up the access
> token data and responds with a JWT formatted introspection response
> (including a fresh jti “abc234567”).
> 3) The RS stores the jti in its replay cache (long with the tokens max
> lifetime)
>
> 4) The client calls the RS again using the same token “123456789”
> 5) The RS calls the introspection endpoint again, the AS looks up the
> access token data and responds with a JWT formatted introspection response
> (including a fresh jti “abc8912345”).
> 6) The RS compares the jti with its replay cache, no hit - it thinks all
> is good and performs the requested transaction.
>
> But it just accepted the same token for the 2nd time.
>
> If the AS would have created JWT formatted introspection responses with
> the same jti, the RS would had a cache hit in step (6) and refused the
> request.
>
> >
> >>
> >> “Active" does not really change, since the introspection response of an
> inactive token is empty except the “active” element.
> >
> > I mean, the token artifact still changes.  What am I supposed to
> interpret
> > "the JWT" as meaning if not the actual encoded artifact?
>
> Sorry I don't understand. Can you please elaborate?
>
> >
> >> So I don’t see issues regarding RFC 7519.
> >>
> >>>
> >>> Section 5 says that:
> >>>
> >>>  If the access token is considered active, it MUST contain the claims
> >>>  "iss" and "aud" in order to prevent misuse of the JWT as an ID or
> >>>  access token (see Section 8.1).
> >>>
> >>> But I don't think the predicate is correct -- misuse is still possible
> >>> by services that do not check the "active" claim's value.  Shouldn't
> the
> >>> "iss"+"aud" requirements be unconditional?
> >>
> >> Introspection responses for inactive tokens won’t contain any data
> except “active”:false. I don’t see how they could be misused and therefore
> think the text is ok.
> >
> > Could you give me a pointer where in the text it says that if "active" is
> > false, no other claims are present?  ("active" only appears three times,
> > but none of them seem to say this.)
>
> Jaap Francke already gave you the pointer.
> @Jaap: thanks.
>
> best regards,
> Torsten.
>
> >
> > -Ben
> >
> >> Please let me know whether you agree with my statements. I would then
> quickly publish a new revision (including changes to address your comments).
> >>
> >> best regards,
> >> Torsten.
> >>
> >>>
> >>>
> >>> --
> >>> COMME

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

[Takahiko Kawasaki]

Hi Torsten,

For example, if an authorization request includes two "resource" request
parameters like below,

resource=https://host1.example.com/resource1
resource=https://host2.example.com/resource2

RFC 8707 expects that the value of "aud" in an introspection response look
like the following.

"aud" : [
  "https://host1.example.com/resource1";,
  "https://host2.example.com/resource2";,
]

How does the implementation of the introspection endpoint insert the
identifier of the resource server (the API caller?) into the "aud" array
above? In other words, what is the expected resultant value of the "aud"
array in this case?

Taka


On Mon, Mar 2, 2020 at 10:54 PM Torsten Lodderstedt 
wrote:

> Hi Taka,
>
> > On 1. Mar 2020, at 08:10, 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 8707 states
>
> The authorization server may use
>the exact "resource" value as the audience or it may map from that
>value to a more general URI or abstract identifier for the given
>resource.
>
> draft-ietf-oauth-jwt-introspection-response-08 states
>
> The value of the "aud" claims MUST identify the resource server
>receiving the token introspection response.
>
> So RFC 8707 gives choices of how the resource server might be identified
> and draft-ietf-oauth-jwt-introspection-response-08 says the AS must
> identify the RS without prescribing any particular way. So basically you
> can use the advice given by  RFC 8707 to implement the requirement stated
> by draft-ietf-oauth-jwt-introspection-response-08.
>
> I don’t see a 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.
>
> I will come back to this issue in an answer to Filip’s post.
>
> best regards,
> Torsten.
>
> >
> > Best Regards,
> > Takahiko Kawasaki
> > Authlete, Inc.
> >
> >
> >
> > ___
> > 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] Conflicting definitions in JWT Response for OAuth Token Introspection

[Takahiko Kawasaki]

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
> <https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08>)
> have already been pointed out.
>
> RFC 8707 <https://tools.ietf.org/html/rfc8707> (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 <https://tools.ietf.org/html/rfc7662> (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
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

Hello,

I'm wondering if the following conflicts in "JWT Response for OAuth Token
Introspection" (draft 8
<https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08>)
have already been pointed out.

RFC 8707 <https://tools.ietf.org/html/rfc8707> (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 <https://tools.ietf.org/html/rfc7662> (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
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JARM

[Takahiko Kawasaki]

I think that JARM is good and even feel that JARM should exist there from a
logical perspective because JARM is to Authorization Response what Request
Object is to Authorization Request. It is good that we don't have to use
"ID Token as Detached Signature" (Financial-grade API Part 2) when JARM is
used.

FWIW, I (Authlete) finished implementing JARM at the beginning of October,
2018, about a year and 3 months ago.

Best Regards,
Takahiko Kawasaki

On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell  wrote:

> I'd be in favor of it.
>
> On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>>
>>
>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>
>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>
>>
>> Since Justin brought it up, I would like to know whether the community
>> has appetite to standardize JARM as well.
>>
>> Here is the link to the spec:
>> https://openid.net/specs/openid-financial-api-jarm-ID1.html
>>
>> What do you think?
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

Well, embedding a client_id claim in the JWE header in order to achieve
"request parameters outside the request object should not be referred to"
is like "putting the cart before the horse". Why do we have to avoid using
the traditional client_id request parameter so stubbornly?

The last paragraph of Section 3.2.1
 of RFC 6749 says as
follows.

*A client MAY use the "client_id" request parameter to identify itself when
sending requests to the token endpoint.  In the "authorization_code"
"grant_type" request to the token endpoint, an unauthenticated client MUST
send its "client_id" to prevent itself from inadvertently accepting a code
intended for a client with a different "client_id".  This protects the
client from substitution of the authentication code.  (It provides no
additional security for the protected resource.)*


If the same reasoning applies, a client_id must always be sent with request
/ request_uri because client authentication is not performed at the
authorization endpoint. In other words, *an unauthenticated client (every
client is unauthenticated at the authorization endpoint) MUST send its
"client_id" to prevent itself from inadvertently accepting a request object
for a client with a different "client_id".*

Best Regards,
Taka



On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov 
wrote:

> 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
>  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 
> 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  *On Behalf Of * John Bradley
>> *Sent:* Friday, January 10, 2020 2:15 PM
>> *To:* Vladimir Dzhuvinov 
>> *Cc:* IETF oauth WG 
>> *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 
>> 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
>> 

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

[Takahiko Kawasaki]

Apparently, the description in the JAR spec has made some AS implementers,
at least Vladimir - Connect2id and Filip - node-oidc-provider, decide to
devise a workaround, and the approach (preparing a configuration switch) is
attracting Taka (me) - Authlete, too. This may be a typical answer by AS
implementers who face compatibility-breaking and interoperability-breaking
issues, although I personally prefer to modify the specification itself to
allow old/new RPs and ASes to coexist seamlessly. If the current draft is
not modified any more, I will probably prepare per-AS and per-RP
configuration switches. Anyway, this is feedback from AS implementers.

If preparing a configuration switch is a typical answer by AS implementers,
it might be good to define a new IdP metadata about JAR support (e.g.
strict, lax, whitelist, as Filip showed). Rather, the existence of such
metadata might be a must for the automated regular tests
<https://gitlab.com/openid/conformance-suite/-/wikis/Users/How-to-be-added-to-the-regular-automated-tests-run>
of conformance suite, but I'm not sure and want to consult Joseph Heenan
regarding this.

Best,
Taka


On Mon, Jan 6, 2020 at 6:43 PM Filip Skokan  wrote:

> I don't think we have the separation of OAuth and non-OAuth parameters and
> let's please not. Even OIDC parameters are part of the OAuth parameters
> registry
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters>
>  and
> I cannot imagine the hardship if we were to explain that to developers.
>
> With passing time I believe it should be up to the profile or application
> of JAR to define how to treat *recognized* parameters outside of the
> request object. In my personal OSS project the AS can be configured to be
> *strict* (jar), *lax* (oidc merge all) or *whitelist* (merge only
> whitelisted - code_challenge, nonce, state, ...) similar to what Vladimir
> is describing.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Mon, 6 Jan 2020 at 07:05, n-sakimura  wrote:
>
>> Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if
>> duplicated.
>>
>> As of -13 (Mar 30, 2017), it was changed that the server does not have to
>> do the merge, at least for OAuth Authorization request parameters. It says
>> nothing about other parameters.
>>
>> As of -14 (Jul 21, 2017), the wording was further strengthened by adding
>>
>>
>>
>> The Authorization Server MUST only use the parameters in the Request
>> Object even if the same parameter is provided in the query parameter.
>>
>>
>>
>> So, the entire 6.3 now became
>> 6.3 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-6.3>..
>> Request Parameter Assembly and Validation
>>
>>The Authorization Server MUST extract the set of Authorization
>>
>>Request parameters from the Request Object value.  The Authorization
>>
>>Server MUST only use the parameters in the Request Object even if the
>>
>>same parameter is provided in the query parameter.  The Authorization
>>
>>Server then validates the request as specified in OAuth 2.0
>>
>>[RFC6749 <https://tools.ietf.org/html/rfc6749>].
>>
>>
>>
>> It says nothing on the non-OAuth parameters that came with the
>> authorization request.
>>
>> My take on the text is that all OAuth Authorization Request parameters
>> MUST be in the request object.
>>
>> Behaviors towards other parameters that happens to have come together
>> with the authorization request outside of request object will be treated as
>> non-OAuth parameters.
>>
>>
>>
>> Nat Sakimura
>>
>> Research Fellow, Nomura Research Institute
>>
>> E: n-sakim...@nri.co.jp
>>
>> T: +81(90)60136276
>>
>> -
>>
>> PLEASE READ:This e-mail is confidential and intended for the named
>> recipient only.
>>
>> If you are not an intended recipient, please notify the sender and delete
>> this e-mail.
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Justin Richer
>> *Sent:* Friday, January 3, 2020 2:35 AM
>> *To:* Takahiko Kawasaki 
>> *Cc:* Brian Campbell ;
>> oauth ; Nat Sakimura 
>> *Subject:* Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs
>> OIDC request object
>>
>>
>>
>> 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.
>

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

[Takahiko Kawasaki]

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 Server*
No problem will happen.

- - -

>From a Client's point of view, for maximum compatibility, both Old and New
Clients should put mandatory request parameters outside the request object
and put all request parameters duplicately inside the request object.

[Problem 3-1] is difficult to detect because the authorization request is
not rejected. But, if New Server requires that all request parameters
outside the request object be put inside the request object duplicately,
[Problem 3-1] is handled as an error and thus client developers can detect
the problem.

Consequently, introducing the following requirement in "FAPI Part 2, 5.2.2
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
10" to JAR seems a good compromise (as I told before)

shall require that all parameters are present inside the signed request
object passed in the request or request_uri parameter;


instead of just saying "the authorization server supporting this
specification MUST only use the parameters included in the request object."
which will bring about [Problem 3-1]. That is, how about adding a rule like
"if request parameters exist outside the request object, they must exist
inside the request object, too."?

Any thoughts?

Best,
Taka


On Fri, Jan 3, 2020 at 12:48 AM Justin Richer  wrote:

> I think the nature of the backwards incompatibility is important here. The
> way that things are now, using merge-with-precedence, you have the
> following matrix of compatibility:
>
>
>  New Server  |  Old Server  |
> ---+-+--+
> New Client |  YES|  NO  |
> Old Client |  YES| YES  |
>
>
> If you ask me, this is the right balance for a breaking change. Old
> clients, where the vast majority of the code is, don’t have to change. New
> clients can only talk to servers with the new features, which is the
> ability to drop parameters from the external request. This would apply to
> both OIDC and plain OAuth.
>
> I think we should follow this kind of pattern in the discussions on OAuth
> 2.1, which I think JAR should be a part of/
>
>  — Justin
>
>
>
> On Jan 2, 2020, at 3:40 AM, Takahiko Kawasaki  wrote:
>
> Breaking backward compatibility in this part would mean that OpenID
> Certification given to AS implementations with request_uri support will be
> invalidated once they support JAR. It also would mean that test cases in
> the official conformance suite need to be changed in a
> backward-incompatible manner, which would implicitly encourage that all
> certified implementations should re-try to get certification.
>
> Changing the spec now might need more three to six months, but it would be
> worth considering what we get and lose by saving the months and breaki

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

[Takahiko Kawasaki]

Breaking backward compatibility in this part would mean that OpenID
Certification given to AS implementations with request_uri support will be
invalidated once they support JAR. It also would mean that test cases in
the official conformance suite need to be changed in a
backward-incompatible manner, which would implicitly encourage that all
certified implementations should re-try to get certification.

Changing the spec now might need more three to six months, but it would be
worth considering what we get and lose by saving the months and breaking
backward compatibility.

Best Regards,
Taka

On Wed, Dec 18, 2019 at 4:14 PM Nat Sakimura  wrote:

> So, no change is OK?
>
> On Wed, Dec 11, 2019 at 10:01 PM John Bradley  wrote:
>
>> I also slightly prefer the merge approach.
>>
>> There are plusses and minuses to both.
>>
>> Changing again now that it is past ISEG review and backing out a Discuss
>> will add another three to six months at this point, if we can get them to
>> agree to the change.
>>
>> John B.
>>
>> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura  wrote:
>>
>>> Correct. The WG supported the precedence approach and even merge just
>>> like OIDC as it is very useful from the implementation point of view and
>>> helps with a bunch of deployment patter.
>>>
>>> The push back came in from the Ben Campbell’s DISCUSS.
>>> See
>>>
>>> https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc-the-current-text-actually-specifies-the
>>>
>>> I am willing to go either way as long as people agree. My slight
>>> preference is to the original approach.
>>>
>>> Best,
>>>
>>> Nat Sakimura
>>>
>>> 2019年8月29日(木) 6:56 Brian Campbell >> 40pingidentity.@dmarc.ietf.org <40pingidentity@dmarc.ietf.org>>:
>>>
 FWIW, as best I can remember the change in question came as I result of 
 directorate/IESG
 review rather than a WG decision/discussion. Which is likely why you can't
 find the "why" anywhere in the mailing list archive.

 On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan 
 wrote:

> Well it kind of blows, doesn't it? I wasn't able to find the "why"
> anywhere in the mailing list archive around the time this was changed..
>
> My take on satisfying both worlds looks like this
>
> - allow just JAR - no other params when possible.
> (which btw isn't possible to do with request_uri when enforcing
> client based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or
> client_id is in request object it must either be missing or the same in
> regular request).
> - allows merging request object and regular parameters with request
> object taking precedence since it is a very useful feature when having
> pre-signed request object that's not one time use and clients using it 
> wish
> to vary state/nonce per-request.
>
> I wish the group reconsidered making this breaking change from OIDC's
> take on request objects - allow combination of parameters from the request
> object with ones from regular parameters (if not present in request 
> object).
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 28 Aug 2019 at 23:02, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
 Filip, for better or worse, I believe your assessment of the situation
>> is correct. I know of one AS that didn't choose which of the two to 
>> follow
>> but rather implemented a bit of a hybrid where it basically ignores
>> everything outside of the request object per JAR but also checks for and
>> enforces the presence and value of the few regular parameters (client_id,
>> response_type) that OIDC mandates.
>>
>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> in an earlier thread I've posed the following question that might
>>> have gotten missed, this might have consequences for the existing
>>> implementations of Request Objects in OIDC implementations - its making
>>> pure JAR requests incompatible with OIDC Core implementations.
>>>
>>> draft 14 of jwsreq (JAR) introduced this language
>>>
>>> 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 thisspecification
 MUST only use the parameters included in the requestobject. *
>>>
>>>
>>> Server MUST only use the parameters in the Request Object even if the
 same parameter is provided in the query parameter.  The
 Authorization
>>>
>>>
>>> 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 supp

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

[Takahiko Kawasaki]

I'm sorry for this late response, but I'm also afraid that the requirement
"the authorization server supporting this specification MUST only use the
parameters included in the request object." in Section 6 of the draft 20
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20> is problematic.

What I'd like to point out in addition to Filip's concerns is "error
handling before the request object is parsed successfully".


   1. If it is not allowed to refer to client_id outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI (which is either
   explicitly specified by redirect_uri or the default redirect URI for the
   client) because it is impossible to check if the redirect URI has been
   registered for the client.
   2. If it is not allowed to refer to response_type outside the request
   object, it is impossible to determine the default position for response
   parameters (the query part and the fragment part) before the request object
   is parsed successfully.
   3. If it is not allowed to refer to response_mode outside the request
   object, errors that may occur before the request object is parsed
   successfully cannot be reported to the redirect URI in the way the client
   wished (query, fragment, form_post, query.jwt, fragment.jwt or
   form_post.jwt).
   4. If it is not allowed to refer to state outside the request object,
   the state cannot be included in error reporting caused by errors that
   may occur before the request object is parsed successfully.


Decent authorization server implementations try to report errors to the
redirect URI whenever possible. If it is not allowed to refer to parameters
outside the request object, the program waiting for a response at the place
pointed to by the redirect URI will never receive
error=invalid_request_object when the cause is "the request object failed
to be parsed".

I haven't found any convincing reasons yet that can justify introducing the
requirement that dares to break the backward compatibility. For me, the
following requirement in FAPI Part 2
<https://openid.net/specs/openid-financial-api-part-2-ID2.html>, 5.2.2.
<https://openid.net/specs/openid-financial-api-part-2-ID2.html#authorization-server>,
10. seems a good compromise.

shall require that all parameters are present inside the signed request
object passed in the request or request_uri parameter;



Best Regards,
Takahiko Kawasaki
Authlete, Inc.



On Thu, Aug 29, 2019 at 5:04 PM Torsten Lodderstedt 
wrote:

>
>
> > Am 28.08.2019 um 23:23 schrieb Filip Skokan :
> >
> > - allows merging request object and regular parameters with request
> object taking precedence since it is a very useful feature when having
> pre-signed request object that's not one time use and clients using it wish
> to vary state/nonce per-request.
>
> +1___
> 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] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Takahiko Kawasaki]

Hi Torsten,

>2.3.1.5.  Request entity too large
>
>   If the request size was beyond the upper bound that the authorization
>   server allows, the authorization server shall return a "413 Request
>   Entity Too Large" HTTP error response.

"413 Request Entity Too Large" should be changed to "413 Payload Too Large"..
c.f.
https://bitbucket.org/openid/fapi/issues/256/pushed-request-object-payload-too-large

>   Depending on client type and authentication method, the request might
>   also include the "client_id" parameter.  The "request_uri"
>   authorization request parameter MUST NOT be provided in this case
>   (see Section 3).

How about changing to:

*the request might also include other request parameters such as the
"client_id" parameter, the "client_secret" parameter, the
"client_assertion" parameter, and so on.*

Taka


On Tue, Oct 1, 2019 at 3:36 PM Justin Richer  wrote:

> To be clear, PAR is not the same as XYZ. Both are going to be inputs into
> the conversation under txauth, and there are similarities, but they
> shouldn’t be conflated.
>
> In PAR, the result has to be a URI because that’s what JAR defines as the
> input. With XYZ, you get returned two things: a transaction handle and an
> interaction URI. These are both opaque to the client.
>
> — Justin
>
> On Sep 30, 2019, at 8:33 AM, Dick Hardt  wrote:
>
> I can understand the request URI being a URI that the client is providing
> the AS, but why would the client's request URI be at the AS?
>
> As Justin has explained it in the past, the AS is returning a handle to
> the transaction. The only party that understands that handle as far as I
> know is the AS. It is meaningless to the client. Perhaps I am missing
> something else?
> ᐧ
>
> On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge 
> wrote:
>
>> So although for this spec, request_uri is just an opaque string, it is
>> defined more generally in
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
>>
>> * Absolute URI from which the Request Object (Section 2.1) can be
>>> obtained*
>>
>>
>> And in section 5.2 as:
>>
>>
>>> *The "request_uri" value MUST be either URN as defined in *
>>> *   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230 *
>>> *   [RFC7230] .  The "request_uri" value MUST be reachable by the **
>>>  Authorization Server.*
>>
>>
>> So this is why in the spec we have example of a URN and we have an
>> ongoing discussion as to whether we should have a standard urn namespace
>> that we recommend implementers use.
>>
>> In the interest of keeping the specs in sync I think it makes sense to
>> keep it a URN for this spec, but with more of an explanation as to why?
>>
>> Dave
>>
>> On Fri, 27 Sep 2019 at 19:22, Dick Hardt  wrote:
>>
>>> If I understand the proposal correctly, the request URI is opaque to the
>>> client. Correct?
>>>
>>> If so, why not just treat it as an opaque string?
>>>
>>> If I were implementing the protocol, I would have the blob be a signed
>>> token so that I could verify the integrity before making a database call.
>>> It much easier to throw compute at a DDOS attack to verify a signature,
>>> than DB capacity.
>>>
>>> ᐧ
>>>
>>> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer  wrote:
>>>
 Yes, the request object is JWT-based, but the request URI is not. In
 other words, you can post a JWT but what you get back is a URI, not the JWT
 itself.  The request URI was always meant to be a reference, and originally
 it was explicitly a reference to a signed request object.

 — Justin

 On Sep 26, 2019, at 10:03 AM, Aaron Parecki  wrote:

 The URI is intended to be a reference not a value.. If the client could
 send a JWT it would just send a request object instead of a request URI in
 the first place. So the intent is that it’s random, and maybe we should
 just say that explicitly.


 I thought this language was explicitly to allow the use of structured
 values for the request_uri? From the introduction:

 but it also allows clients requiring an even
 higher security level, especially cryptographically confirmed non-
 repudiation, to explicitly adopt JWT-based request objects.


 
 Aaron Parecki
 aaronparecki.com

 On Thu, Sep 26, 2019 at 6:49 PM Justin Richer  wrote:


 Aaron, some comments inline.

 — Justin

 On Sep 26, 2019, at 8:30 AM, Aaron Parecki  wrote:

 Hi Torsten,

 I'm very glad to see this draft, I think it's definitely needed in
 this space. Here are some of my thoughts on the draft.

 "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"


 Is it acceptable for the AS to return just an opaque string, rather
 than something prefixed with "uri:*"? I don't think anyone would be
 confused about copypasting the exact string from the "request_uri"
 response into the "request_uri" parameter even if it didn't start with
 "ur

Re: [OAUTH-WG] ID Token by Device Flow

[Takahiko Kawasaki]

Hi Justin,

Thank you. Consensus will be that "openid" in the "scope" request parameter
should trigger generation of an ID token. I'm wondering if the WG plans to
mention it explicitly in the spec and add "acr_values" request parameter.

Best Regards,
Taka


2019年6月25日(火) 1:13 Justin Richer :

> Taka,
>
> My reading is that the device flow, like other OAuth flows, does not
> prohibit extension, including passing back identity assertions like the ID
> Token. Since it inherits the token response from core OAuth 2, the ID Token
> could be issued along side the access token just like in the authorization
> code flow.The user is present and interacting at the AS in both cases. In
> fact, I’d say that there are enough similarities between the two that for
> the most part it should “just work” and fit the assumptions of most
> clients. That said, it’s technically true that there is no defined profile
> for the combination of the device flow and OIDC, but if something like that
> were to be written it would be better fit to the OpenID Foundation.
>
> — Justin
>
> On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki  wrote:
>
> Hello,
>
> Do you have any plan to update the specification of Device Flow to support
> issue of ID tokens?
>
> OAuth 2.0 Device Authorization Grant
>
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1
>
> Best Regards,
> Takahiko Kawasaki
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] ID Token by Device Flow

[Takahiko Kawasaki]

Hello,

Do you have any plan to update the specification of Device Flow to support
issue of ID tokens?

OAuth 2.0 Device Authorization Grant
https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1

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

Re: [OAUTH-WG] Client Authentication Method at Device Authorization Endpoint

[Takahiko Kawasaki]

Dear Filip,

Thank you for your comment. Historically, metadata related to client
authentication methods have been defined for each endpoint such as token
endpoint, introspection endpoint and revocation endpoint. When defining the
CIBA specification, we discussed whether to define a new metadata for
client authentication methods for the backchannel authentication endpoint.
The final decision is "not define but reuse metadata defined for token
endpoint". See Issue 102 "CIBA: Metadata for client auth at backchannel
endpoint" <https://bitbucket.org/openid/mobile/issues/102> of MODRNA WG for
details. This is the reason the CIBA specification explicitly says as
follows:


*The token_endpoint_auth_method indicates the registered authentication
method for the client to use when making direct requests to the OP,
including requests to both the token endpoint and the backchannel
authentication endpoint.*

What I'm asking is whether to (1) allow authorization server
implementations to auto-detect the client authentication method used by a
device authorization request at runtime based on request parameters such as
(a) client_id & client_secret (client_secret_post), (b) client_assertion &
client_assertion_type (client_secret_jwt or private_key_jwt), (c)
Authorization header (client_secret_basic) or (d) a client certificate
(tls_client_auth or self_signed_tls_client_auth), or (2) use the
pre-configured client authentication method only and reject/ignore other
client authentication methods. For the latter case, one more point is
whether to (1) define a new metadata that represents the client
authentication method at the device authorization endpoint or (2) reuse the
existing metadata defined for the token endpoint.

Best Regards,
Takahiko Kawasaki

2019年6月4日(火) 14:33 Filip Skokan :

> Hello Takahiko,
>
> Such language already exists in second to last paragraph of section 3.1.
> Like with CIBA the client’s regular token endpoint auth method is used at
> the device authorization endpoint.
>
> > The client authentication requirements of Section 3.2.1 of [RFC6749] 
> > <https://tools.ietf.org/html/rfc6749#section-3.2.1>
>apply to requests on this endpoint, which means that confidential
>clients (those that have established client credentials) authenticate
>in the same manner as when making requests to the token endpoint, and
>public clients provide the "client_id" parameter to identify
>themselves.
>
>
> Odesláno z iPhonu
>
> 4. 6. 2019 v 4:10, Takahiko Kawasaki :
>
> Hello,
>
> Do you have any plan to define a rule as to which client authentication
> method should be used at the device authorization endpoint (which is
> defined in OAuth 2.0 Device Authorization Grant
> <https://datatracker..ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1>
> )?
>
> Section 4 of CIBA
> <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>,
> which has incorporated some ideas/rules/parameters from Device Flow, says
> as follows.
>
>
> *The token_endpoint_auth_method indicates the registered authentication
> method for the client to use when making direct requests to the OP,
> including requests to both the token endpoint and the backchannel
> authentication endpoint.*
>
> This means that a backchannel authentication endpoint in CIBA (which
> corresponds to a device authorization endpoint in Device Flow) performs
> client authentication using the client authentication method specified by
> the token_endpoint_auth_method metadata of the client.
>
> I'd like to know if you have any plan to explicitly add a description like
> above into the specification of OAuth 2.0 Device Authorization Grant.
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Client Authentication Method at Device Authorization Endpoint

[Takahiko Kawasaki]

Hello,

Do you have any plan to define a rule as to which client authentication
method should be used at the device authorization endpoint (which is
defined in OAuth 2.0 Device Authorization Grant
<https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1>
)?

Section 4 of CIBA
<https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>,
which has incorporated some ideas/rules/parameters from Device Flow, says
as follows.


*The token_endpoint_auth_method indicates the registered authentication
method for the client to use when making direct requests to the OP,
including requests to both the token endpoint and the backchannel
authentication endpoint.*

This means that a backchannel authentication endpoint in CIBA (which
corresponds to a device authorization endpoint in Device Flow) performs
client authentication using the client authentication method specified by
the token_endpoint_auth_method metadata of the client.

I'd like to know if you have any plan to explicitly add a description like
above into the specification of OAuth 2.0 Device Authorization Grant.

Best Regards,
Takahiko Kawasaki
Authlete, Inc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] aud in JWT Response for OAuth Token Introspection

[Takahiko Kawasaki]

Hello,

I have a question regarding "JWT Response for OAuth Token Introspection"
(draft-02).

https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/?include_text=1

How to determine the value of "aud" in the response JWT?

The example payload uses "https://protected.example.net/resource"; as the
value of "aud". The example value implies that it represents the identifier
of the target resource or the resource server, but how does an
authorization server implementation know the identifier? I'm sorry if this
has already been discussed.

To be honest, I fear that some inconsistencies might occur in future by
treating resource servers as clients. If I had to write the specification,
I would start from defining "resource server metadata" (e.g. expired draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/) and
devising a way to register resource servers into an authorization server
and issue resource server credentials (e.g. rs_id and rs_secret, RS JWK
Set, etc.) in order to treat resource servers and clients as different
entities explicitly. I hope that discussion for distinguishing "resource
server authentication" from "client authentication" will be initiated
sometime in future.

Best Regards,
Takahiko Kawasaki
Authlete, Inc.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Takahiko Kawasaki]

Dear Torsten,

To the point. (^_^; It is "request object". Sorry.

Best,
Taka


2019年4月30日(火) 19:24 Torsten Lodderstedt :

> Dear Taka,
>
> thanks for your feedback.
>
> How would this more generic mechanism differ from the JSON-based request
> object? I personally would advocate to use both, structured scope & pushed
> request object, to together.
>
> best regards,
> Torsten.
>
> Am 26.04.2019 um 09:47 schrieb Takahiko Kawasaki :
>
> Dear Torsten,
>
> I was impressed with your article. It describes considerations points very
> well that implementers of leading-edge authorization servers will
> eventually face or have already faced.
>
> It seems to me that the mechanism of "structured_scope" can be positioned
> as a more generic mechanism whose usage doesn't necessarily have to be
> limited to scopes. I mean that the mechanism can be used to include any
> arbitrary dynamic structured data in an authorization request. So, if there
> were something I might be able to propose additionally, I would suggest
> renaming "structured_scope" to a more generic name.
>
> Best Regards,
> Takahiko Kawasaki
> Representative director, Authlete, Inc.
>
> 2019年4月21日(日) 3:21 Torsten Lodderstedt :
>
>> Hi all,
>>
>> I just published an article about the subject at:
>> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>>
>>
>> I look forward to getting your feedback.
>>
>> kind regards,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Takahiko Kawasaki]

Dear Torsten,

I was impressed with your article. It describes considerations points very
well that implementers of leading-edge authorization servers will
eventually face or have already faced.

It seems to me that the mechanism of "structured_scope" can be positioned
as a more generic mechanism whose usage doesn't necessarily have to be
limited to scopes. I mean that the mechanism can be used to include any
arbitrary dynamic structured data in an authorization request. So, if there
were something I might be able to propose additionally, I would suggest
renaming "structured_scope" to a more generic name.

Best Regards,
Takahiko Kawasaki
Representative director, Authlete, Inc.

2019年4月21日(日) 3:21 Torsten Lodderstedt :

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-04.txt

[Takahiko Kawasaki]

Dear Brian,

I'd like to make some small comments.

2. / 1st paragraph / 4th line
"for client authentications" --> "for client authentication"
(remove 's' at the end)

2.1.1. / 1st paragraph / 4th line
"used to indicated" -> "used to indicate"
(remove 'd' at the end)

2.2. / 1st paragraph / 3rd line
"a X.509 certificate" -> "an X.509 certificate"
(replace "a" with "an")

2.2. / 1st paragraph / 11th line
"info of one the" -> "info of one of the"
(insert "of" between "one" and "the")

2.2. / 1st paragraph / 17th line
"directly with at the" -> "directly at the"
(remove "with")

2.2.1. / 1st paragraph / 4th line
"used to indicated" -> "used to indicate"
(remove 'd' at the end)

3.1. / 1st paragraph / 1st line
"as a JSON Web Tokens" -> "as JSON Web Tokens"
(remove 'a')

3.1. / 2nd paragraph / 6th-7th lines
"are also sometimes also" -> "are sometimes also"
(remove one "also")

3.3. & 3.4.
After reading the specification, for me, "certificate_bound_access_tokens"
sounds more natural than "mutual_tls_sender_constrained_access_tokens". Is
there any special reason for the parameter name?

4.3. / 1st paragraph / 1st line
"allows for the use" -> "allows use"
(remove "for the", but I'm not sure because I'm not a native English
speaker.)

6.1. / 1st paragraph / 2nd line
"it is latest" -> "it is the latest"
(insert "the" between "is" and "latest")

By the way, isn't it necessary to define rules for REFRESH tokens? For
example, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound to
the same certificate. When the token endpoint of the authorization server
receives a refresh token request with a certificate-bound refresh token,
..."

Best Regards,
Taka


2017-10-13 17:31 GMT+01:00 Brian Campbell :

> Thanks for the review, Vladimir. And yes, sender-constrained access tokens
> should also work in a token exchange scenario.
>
> On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> Superb! Thanks for putting down everything that was discussed. I read the
>> new version and have zero comments about it.
>>
>> Will sender-constrained access tokens also work in a token exchange
>> scenario?
>>
>> (draft-ietf-oauth-token-exchange-09)
>>
>> Vladimir
>>
>> On 13/10/17 01:07, Brian Campbell wrote:
>>
>> I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth
>> 2.0" has been published. The changes, based on feedback and discussion on
>> this list over the last two months, are listed below.
>>
>>
>> draft-ietf-oauth-mtls-04
>>  
>>
>>o  Change the name of the 'Public Key method' to the more accurate
>>   'Self-Signed Certificate method' and also change the associated
>>   authentication method metadata value to
>>   "self_signed_tls_client_auth".
>>o  Removed the "tls_client_auth_root_dn" client metadata field as
>>   discussed in 
>> https://mailarchive.ietf.org/arch/msg/oauth/
>>  
>>   
>> swDV2y0be6o8czGKQi1eJV-g8qc
>>  
>>o  Update 
>> draft-ietf-oauth-discovery
>>   reference to
>> -07
>>o  Clarify that MTLS client authentication isn't exclusive to the
>>   token endpoint and can be used with other endpoints, e.g.  
>> RFC 
>> 
>>   7009  
>>  revocation and 7662
>> introspection, that utilize client
>>   authentication as discussed in
>>   
>> https://mailarchive.ietf.org/arch/msg/oauth/
>>  
>>   
>> bZ6mft0G7D3ccebhOxnEYUv4puI
>>  
>>
>>o  Reorganize the document somewhat in an attempt to more clearly
>>   make a distinction between mTLS client authentication and
>>   certificate bound access tokens as well as a more clear
>>   delineation between the two (PKI/Public key) methods for client
>>   authentication
>>o  Editorial fixes and clarifications
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Thu, Oct 12, 2017 at 3:50 PM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
>> To: i-d-annou...@ietf.org
>> Cc: oauth@ietf.org
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> dire

Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

[Takahiko Kawasaki]

Thank you.


If it is allowed that an "unspecified" behavior can be not only "not work
correctly" but also "work correctly (as if scope included openid)", the
condition "REQUIRED. OpenID Connect requests MUST contain the openid scope
value" is not necessary (it doesn't have to say REQUIRED and MUST).
Therefore, my natural interpretation is that an "unspecified" behavior is
"not work correctly".


However, this is my interpretation. If the interpretation is not a majority,
I should accept that the example in "5. Definitions of Multi-Valued
Response Type Combinations" is allowed as an unspecified behavior.


Best Regards,

Takahiko Kawasaki

2017-06-27 5:42 GMT+09:00 George Fletcher :

> From section 3.1.2.1 of the OpenID Connect Core...
>
> scope REQUIRED. OpenID Connect requests MUST contain the openid scope
> value. *If the* *openid* *scope value is not present, the behavior is
> entirely unspecified.* Other scope values MAY be present. Scope values
> used that are not understood by an implementation SHOULD be ignored. See
> Sections 5.4
> <http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims> and 11
> <http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess> for
> additional scope values defined by this specification.
> In this light, there is no specification that covers the behavior of the
> AS given the authorization request you provided.
>
> At least that is my reading of the specs.
>
> Thanks,
> George
>
>
> On 6/26/17 1:59 PM, Takahiko Kawasaki wrote:
>
> Thank you. Please let me ask a simplified question.
>
> If an authorization server returns this response (including id_token):
>
>   HTTP/1.1 302 Found
>   Location: https://client.example.org/cb#
>   access_token=SlAV32hkKG
>   &token_type=bearer
>   &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
>   &expires_in=3600
>   &state=af0ifjsldkj
>
> when it receives this request (without scope=openid):
>
>   GET /authorize?
> response_type=id_token%20token
> &client_id=s6BhdRkqt3
> &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
> &state=af0ifjsldkj HTTP/1.1
>   Host: server.example.com
>
> , is the implementation of the authorization server correct?
>
> Best Regards,
> Takahiko Kawasaki
>
>
> 2017-06-26 21:53 GMT+09:00 Philippe Signoret  com>:
>
>> None of the examples in that spec are _*OpenID Connect*_ authentication
>> requests. They are, however, valid _*OAuth 2.0**_* authorization
>> requests. The one in question demonstrates use of the
>> response_mode=id_token, as defined in the realm of OAuth 2.0. If (and only
>> if) it had scope=openid, _*then*_ it would become an OpenID Connect auth
>> request, and the OpenID Connect specs would apply.
>>
>>
>>
>> In other words, the fact that id_token is in the response_type does _
>> *not**_ *automatically make it an OpenID Connect request.
>>
>>
>>
>> Another way of seeing it is that the OAuth 2.0 Multiple Response Type
>> Encoding spec is laying some foundations, as part of the OAuth 2.0
>> framework, upon which OpenID Connect is then built.
>>
>>
>>
>> In Section 11.3. OAuth Authorization Endpoint Response Types Registry
>> <https://tools.ietf.org/html/rfc6749#section-11.3>, the OAuth 2.0 spec
>> (RFC 6749) defines a registry of response types:
>>
>>
>>
>>This specification establishes the OAuth Authorization Endpoint
>>
>>Response Types registry.
>>
>>
>>
>> Then, in Section 3, ID Token Response Type
>> <http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token>,
>> OAuth 2.0 Multiple Response Types registers “id_token” as a response type
>> in that same registry:
>>
>>
>>
>> This section registers a new Response Type, the id_token, in accordance
>> with the stipulations in the OAuth 2.0 specification, Section 8.4. The
>> intended purpose of the id_token is that it MUST provide an assertion of
>> the identity of the Resource Owner as understood by the Authorization
>> Server. The assertion MUST specify a targeted audience, e.g. the requesting
>> Client. However, the specific semantics of the assertion and how it can be
>> validated are not specified in this document.
>>
>>
>>
>> Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines
>> (amongst other things) that including “scope=openid” is how the client
>> indicates that this is an OpenID Connect request, makes use of the
>> previously registered Response Type “id_to

Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

[Takahiko Kawasaki]

Thank you. Please let me ask a simplified question.

If an authorization server returns this response (including id_token):

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj

when it receives this request (without scope=openid):

  GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

, is the implementation of the authorization server correct?

Best Regards,
Takahiko Kawasaki


2017-06-26 21:53 GMT+09:00 Philippe Signoret <
philippe.signo...@microsoft.com>:

> None of the examples in that spec are _*OpenID Connect*_ authentication
> requests. They are, however, valid _*OAuth 2.0**_* authorization
> requests. The one in question demonstrates use of the
> response_mode=id_token, as defined in the realm of OAuth 2.0. If (and only
> if) it had scope=openid, _*then*_ it would become an OpenID Connect auth
> request, and the OpenID Connect specs would apply.
>
>
>
> In other words, the fact that id_token is in the response_type does _*not**_
> *automatically make it an OpenID Connect request.
>
>
>
> Another way of seeing it is that the OAuth 2.0 Multiple Response Type
> Encoding spec is laying some foundations, as part of the OAuth 2.0
> framework, upon which OpenID Connect is then built.
>
>
>
> In Section 11.3. OAuth Authorization Endpoint Response Types Registry
> <https://tools.ietf.org/html/rfc6749#section-11.3>, the OAuth 2.0 spec
> (RFC 6749) defines a registry of response types:
>
>
>
>This specification establishes the OAuth Authorization Endpoint
>
>Response Types registry.
>
>
>
> Then, in Section 3, ID Token Response Type
> <http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token>,
> OAuth 2.0 Multiple Response Types registers “id_token” as a response type
> in that same registry:
>
>
>
> This section registers a new Response Type, the id_token, in accordance
> with the stipulations in the OAuth 2.0 specification, Section 8.4. The
> intended purpose of the id_token is that it MUST provide an assertion of
> the identity of the Resource Owner as understood by the Authorization
> Server. The assertion MUST specify a targeted audience, e.g. the requesting
> Client. However, the specific semantics of the assertion and how it can be
> validated are not specified in this document.
>
>
>
> Finally, on that OAuth 2.0 foundation, the OpenID Connect spec defines
> (amongst other things) that including “scope=openid” is how the client
> indicates that this is an OpenID Connect request, makes use of the
> previously registered Response Type “id_token” (in some flows—other flows
> don’t use the “id_token” response type), and proceeds to specify the format
> and contents of the ID Token:
>
>
>
> OpenID Connect implements authentication as an extension to the OAuth 2.0
> authorization process. Use of this extension is requested by Clients by
> including the openid scope value in the Authorization Request.
> Information about the authentication performed is returned in a *JSON Web
> Token (JWT)* <http://openid.net/specs/openid-connect-core-1_0.html#JWT> [JWT]
> called an ID Token (see *Section 2*
> <http://openid.net/specs/openid-connect-core-1_0.html#IDToken>).
>
>
>
> Philippe
>
>
>
> *From:* Takahiko Kawasaki [mailto:daru...@gmail.com]
> *Sent:* Monday, June 26, 2017 2:17 PM
> *To:* Philippe Signoret 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type
> Encoding Practices
>
>
>
> The response_type of the example includes id_token and it is the reason
> I've brought it up. id_token triggers Authentication Request.
>
>
>
> # The response_type in the example in Appendix A
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23FragmentExample&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C092adcaef9954edf8e3208d4bc8d2fba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340761951990482&sdata=mRz8ViYA0cYXXO4iVw1vAgO4Xejh%2FDcxYegTfdeOSBw%3D&reserved=0>
> does not include id_token and so I've not mentioned it.
>
>
>
> Best,
>
> Taka
>
>
>
>
>
>
>
> 2017-06-26 17:09 GMT+09:00 Philippe Signoret  com>:
>
> scope=openid is required for OpenID Connect Authentication Requests (e.g.
> "3.3.2.1. Authentication Request
> <https://na01.safelinks.protection.outlook.com

Re: [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

[Takahiko Kawasaki]

The response_type of the example includes id_token and it is the reason
I've brought it up. id_token triggers Authentication Request.

# The response_type in the example in Appendix A
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#FragmentExample>
does not include id_token and so I've not mentioned it.

Best,
Taka



2017-06-26 17:09 GMT+09:00 Philippe Signoret <
philippe.signo...@microsoft.com>:

> scope=openid is required for OpenID Connect Authentication Requests (e.g.
> "3.3.2.1. Authentication Request
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>"
> in "OpenID Connect Core 1.0
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=FrFLKpyHVfZbRw1OsOs7QH%2F2bSrJbJluKnny0X%2FiJxw%3D&reserved=0>"),
> but not for an OAuth 2.0 Authorization Request (e.g. "4.1.1.
> Authorization Request <https://tools.ietf.org/html/rfc6749#section-4.1.1>"
> in "RFC6749 The OAuth 2.0 Authorization Framework
> <https://tools.ietf.org/html/rfc6749>").
>
>
>
> OpenID Connect is “an identity layer on top of the OAuth 2.0 protocol”.
> OpenID Connect specs will often refer to aspects of the OAuth 2.0 protocol,
> but the OAuth 2.0 specs will generally not refer to the OpenID Connect
> constructs. (Because OpenID Connect is a specific case of OAuth 2.0.)
>
>
>
> Philippe
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Takahiko
> Kawasaki
> *Sent:* Monday, June 26, 2017 7:46 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Example in OAuth 2.0 Multiple Response Type
> Encoding Practices
>
>
>
> Hello,
>
>
>
> I'm not so sure that this is the right place to ask, but I'm wondering
> whether it is correct or not that the following non-normative example found
> in "5. Definitions of Multi-Valued Response Type Combinations
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html%23Combinations&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=A2%2F5R%2FFDSMUN8lthoex%2BAnF3h%2FouQHjXBPhW3Yv5D7M%3D&reserved=0>"
> in "OAuth 2.0 Multiple Response Type Encoding Practices
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Foauth-v2-multiple-response-types-1_0.html&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=oax1ui3n46P2n67Mqx14t0458TZjrcw9IUsdCoGsmho%3D&reserved=0>"
> does not include "scope=openid".
>
>
>
>   GET /authorize?
>
> response_type=id_token%20token
>
> &client_id=s6BhdRkqt3
>
> &redirect_uri=https%3A%2F%2Fclient.example.org 
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F2Fclient.example.org&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=%2BaCAvhV9qt75Cqajdrr84BVG6MRS3747Ux5CsjJtgQE%3D&reserved=0>%2Fcb
>
> &state=af0ifjsldkj HTTP/1.1
>
>   Host: server.example.com 
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fserver.example.com&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=PoXzHooKqVnYx4pzWD%2B4THUElRZjsUC2TNdMlTrhfiY%3D&reserved=0>
>
>
>
> The reason I'm wondering is that "3.3.2.1. Authentication Request
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23HybridAuthRequest&data=02%7C01%7CPhilippe.Signoret%40microsoft.com%7C7ae0944f524d4655cb6c08d4bc56b163%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340527913704845&sdata=HO6gAigTdBjgxOhsS41bKLbbl1cUyUugvXBjJ4hwmKE%3D&reserved=0>"
> in "OpenID Connect Core 1.0
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html&data=02%7C01

[OAUTH-WG] Example in OAuth 2.0 Multiple Response Type Encoding Practices

[Takahiko Kawasaki]

Hello,

I'm not so sure that this is the right place to ask, but I'm wondering
whether it is correct or not that the following non-normative example found
in "5. Definitions of Multi-Valued Response Type Combinations
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations>"
in "OAuth 2.0 Multiple Response Type Encoding Practices
<http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>" does
not include "scope=openid".

  GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&state=af0ifjsldkj HTTP/1.1
  Host: server.example.com


The reason I'm wondering is that "3.3.2.1. Authentication Request
<http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest>"
in "OpenID Connect Core 1.0
<http://openid.net/specs/openid-connect-core-1_0.html>" requires
Authentication Requests be made as defined in "3.1.2.1. Authentication
Request <http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest>"
and "3.1.2.1" requires the scope request parameter contain openid.


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

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-binding-03.txt

[Takahiko Kawasaki]

Dear Brian,

Just a small editorial issue on the 4th line in the 2nd paragraph in "*2.1.
Example Token Binding for Refresh Tokens".* "the" should be removed from
"the of PKCS is".

Best Regards,
Takahiko Kawasaki



2017-03-28 1:32 GMT+09:00 Brian Campbell :

> -03 only fixes a few mistakes in and around the examples that I noticed
> preparing the slides for the IETF 98 Chicago meeting.
>
> -- Forwarded message --
> From: 
> Date: Mon, Mar 27, 2017 at 11:31 AM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-03.txt
> To: i-d-annou...@ietf.org
> Cc: oauth@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
> Title   : OAuth 2.0 Token Binding
> Authors : Michael B. Jones
>   John Bradley
>   Brian Campbell
>   William Denniss
> Filename: draft-ietf-oauth-token-binding-03.txt
> Pages   : 26
> Date: 2017-03-27
>
> Abstract:
>This specification enables OAuth 2.0 implementations to apply Token
>Binding to Access Tokens, Authorization Codes, and Refresh Tokens.
>This cryptographically binds these tokens to a client's Token Binding
>key pair, possession of which is proven on the TLS connections over
>which the tokens are intended to be used.  This use of Token Binding
>protects these tokens from man-in-the-middle and token export and
>replay attacks.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-03
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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] Fwd: I-D Action: draft-ietf-oauth-mtls-01.txt

[Takahiko Kawasaki]

Dear Brian,

Thank you for having fixed it.

I don't think my name should be listed in the document just for this,
though. It's too unbalanced considering others' contribution...

Best,
Taka


2017-06-12 20:57 GMT+09:00 Brian Campbell :

> Thanks Takahiko, mentioning it on the list is enough. I've fixed it in
> the editors' draft https://github.com/ietf-oauth-mtls/i-d/commit/
> c6725e30dd1dc2f77aa293bce7fd1849713ed406
>
> On Mon, Jun 12, 2017 at 5:33 AM, Takahiko Kawasaki 
> wrote:
>
>> Hello,
>>
>> I'm sorry for this FAQ but where can I make comments for the draft of
>> "Mutual TLS Profiles for OAuth Clients"?
>>
>> I found a trivial editorial issue in the last paragraph in "3. Mutual TLS
>> Sender Constrained Resources Access". The second 'that' in "... verify that
>> the that certificate matches ..." should be removed (= that part should be
>> "... verify that the certificate matches ..."). Is it enough to mention it
>> in this mailing list like this?
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>> 2017-05-27 5:34 GMT+09:00 Brian Campbell :
>>
>>> A new draft of "Mutual TLS Profiles for OAuth Clients" has been published. 
>>> The changes from the previous version are summarized below.
>>>
>>>
>>>draft-ietf-oauth-mtls-01 
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01>
>>>
>>>o  Added more explicit details of using RFC 7662 
>>> <https://datatracker.ietf.org/doc/html/rfc7662> token introspection
>>>   with mutual TLS sender constrained access tokens.
>>>o  Added an IANA OAuth Token Introspection Response Registration
>>>   request for "cnf".
>>>o  Specify that tls_client_auth_subject_dn and
>>>   tls_client_auth_root_dn are RFC 4514 
>>> <https://datatracker.ietf.org/doc/html/rfc4514> String Representation of
>>>   Distinguished Names.
>>>o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
>>>o  Changed the text in the Section 3 
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01#section-3> 
>>> to not be specific about using a
>>>   hash of the cert.
>>>o  Changed the abbreviated title to 'OAuth Mutual TLS' (previously
>>>   was the acronym MTLSPOC).
>>>
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From: 
>>> Date: Fri, May 26, 2017 at 2:26 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
>>> To: i-d-annou...@ietf.org
>>> Cc: oauth@ietf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol of the IETF.
>>>
>>> Title   : Mutual TLS Profiles for OAuth Clients
>>> Authors : Brian Campbell
>>>   John Bradley
>>>   Nat Sakimura
>>>   Torsten Lodderstedt
>>> Filename: draft-ietf-oauth-mtls-01.txt
>>> Pages   : 12
>>> Date: 2017-05-26
>>>
>>> Abstract:
>>>This document describes Transport Layer Security (TLS) mutual
>>>authentication using X.509 certificates as a mechanism for both OAuth
>>>client authentication to the token endpoint as well as for sender
>>>constrained access to OAuth protected resources.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-01
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-01
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-01.txt

[Takahiko Kawasaki]

Hello,

I'm sorry for this FAQ but where can I make comments for the draft of
"Mutual TLS Profiles for OAuth Clients"?

I found a trivial editorial issue in the last paragraph in "3. Mutual TLS
Sender Constrained Resources Access". The second 'that' in "... verify that
the that certificate matches ..." should be removed (= that part should be
"... verify that the certificate matches ..."). Is it enough to mention it
in this mailing list like this?

Best Regards,
Takahiko Kawasaki

2017-05-27 5:34 GMT+09:00 Brian Campbell :

> A new draft of "Mutual TLS Profiles for OAuth Clients" has been published. 
> The changes from the previous version are summarized below.
>
>
>draft-ietf-oauth-mtls-01 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01>
>
>o  Added more explicit details of using RFC 7662 
> <https://datatracker.ietf.org/doc/html/rfc7662> token introspection
>   with mutual TLS sender constrained access tokens.
>o  Added an IANA OAuth Token Introspection Response Registration
>   request for "cnf".
>o  Specify that tls_client_auth_subject_dn and
>   tls_client_auth_root_dn are RFC 4514 
> <https://datatracker.ietf.org/doc/html/rfc4514> String Representation of
>   Distinguished Names.
>o  Changed tls_client_auth_issuer_dn to tls_client_auth_root_dn.
>o  Changed the text in the Section 3 
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01#section-3> to 
> not be specific about using a
>   hash of the cert.
>o  Changed the abbreviated title to 'OAuth Mutual TLS' (previously
>   was the acronym MTLSPOC).
>
>
>
>
> -- Forwarded message --
> From: 
> Date: Fri, May 26, 2017 at 2:26 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-01.txt
> To: i-d-annou...@ietf.org
> Cc: oauth@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
> Title   : Mutual TLS Profiles for OAuth Clients
> Authors : Brian Campbell
>   John Bradley
>   Nat Sakimura
>   Torsten Lodderstedt
> Filename: draft-ietf-oauth-mtls-01.txt
> Pages   : 12
> Date: 2017-05-26
>
> Abstract:
>This document describes Transport Layer Security (TLS) mutual
>authentication using X.509 certificates as a mechanism for both OAuth
>client authentication to the token endpoint as well as for sender
>constrained access to OAuth protected resources.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-01
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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] TAuth

[Takahiko Kawasaki]

IMHO,

The reason an OAuth 2.0 server does not authenticate _public_ clients is
because, by definition, a public client cannot keep its client secret
confidential and so client authentication is almost meaningless.

"Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're
fixing it" and the famous post "OAuth 2.0 and the Road to Hell" (by Mr.
Eran Hammer) blame OAuth 2.0, but they don't recognize that their
insistence relies on the assumption that a secret key embedded in a client
application can be kept confidential. On the other hand, OAuth 2.0
recognizes that the assumption is naive under some conditions and
explicitly distinguishes confidential clients from public clients (RFC
6749, 2.1. Client Types).

It sounds unconvincing to me that people who live in the 'confidential
client' world blame OAuth 2.0 which covers use cases for both confidential
clients and public clients.

My opinion with further details is written in my answer to the question
"How is OAuth 2 different from OAuth 1?" in StackOverflow.

http://stackoverflow.com/a/35775049/1174054


Best Regards,
Takahiko Kawasaki

2016-05-11 9:22 GMT+09:00 Dick Hardt :

> Let us know what you learn Justin!
>
> On Tue, May 10, 2016 at 5:05 PM, Justin Richer  wrote:
>
>> I posted about this the other day. What I don't understand is that he's
>> saying people disable TLS checks so he's going to solve it with mutual TLS?
>>
>> I need to email this guy and learn more about what he's doing.
>>
>> --Justin
>>
>>  *Sent from my phone*
>>
>>  Original message 
>> From: Brock Allen 
>> Date: 5/10/16 6:44 PM (GMT-06:00)
>> To: Dick Hardt , Oauth Wrap Wg 
>> Subject: Re: [OAUTH-WG] TAuth
>>
>> Doesn’t the recent PoP work address many of these concerns?
>>
>> Also, as for developers disabling SSL — does anyone still do this and
>> think it’s safe? Or are people just being lazy? Or are there certain
>> contexts that I’m unaware of where this is valid?
>>
>> -Brock
>>
>>
>> From: OAuth  on behalf of Dick Hardt <
>> dick.ha...@gmail.com>
>> Date: Tuesday, May 10, 2016 at 7:24 PM
>> To: Oauth Wrap Wg 
>> Subject: [OAUTH-WG] TAuth
>>
>> Does anyone think there are useful lessons here?
>>
>> Does adding TOKBIND resolve the issues?
>>
>> https://blog.teller.io/2016/04/26/tauth.html
>>
>> *Teller* <https://blog.teller.io/>
>>
>> Join waiting list <http://teller.io/#waitlist>
>>
>> Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're
>> fixing it
>>
>> This week we released our authorisation flow making it possible for you
>> to go from building apps that talk to your bank account, to building apps
>> that can talk to any bank account. This is huge. Check out this SMS bot
>> (how on trend) I hacked up yesterday morning. (and don't forget to join
>> the beta wait list <https://teller.io/>).
>>
>>
>> Getting to this point took longer than we expected. This is because there
>> wasn't a good story for delegating authorisation for sensitive APIs. The
>> most popular choice, OAuth 2.0 <http://oauth.net/2> - which has been
>> chosen by the Open Banking Working Group
>> <http://theodi.org/open-banking-standard>, BBVA
>> <https://www.bbvaapimarket.com/web/api_market/bbva/bbva-connect/documentation#3-legged-flow>,
>> RBS <https://bluebank.portal.azure-api.net/getting-started>, and Mondo
>> <https://getmondo.co.uk/docs/#authentication> - is also amongst the
>> worst from a security perspective.
>>
>> Teller provides an API for your bank account. The EU is forcing all
>> European banks to expose account APIs with PSD II
>> <http://ec.europa.eu/finance/payments/framework/index_en.htm> by end of
>> 2017. These banks are disconcertingly converging around OAuth 2.0* without
>> fully considering the impact on their customers, and something needs to be
>> done before it's too late.
>>
>> * One notable exception is the Open Bank Project
>> <http://www.openbankproject.com/>. It is sticking with OAuth 1.0a
>> <http://oauth.net/core/1.0a/> precisely because OAuth 1.0a doesn't share
>> the same security issues as OAuth 2.0.
>>
>> Man-in-the-middle
>>
>> One of the biggest problems with OAuth 2.0 is that it delegates all
>> security concerns to TLS but only the client authenticates the server (via
>> it's SSL certificate), the server does not authenticate the client. This
>> means the server has no way of

[OAUTH-WG] Multiple authorization servers for one resource server

[Takahiko Kawasaki]

Hello,

I have a question.

If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.

Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

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

Re: [OAUTH-WG] Password in plaintext in emails from mailmain-ow...@ietf.org

[Takahiko Kawasaki]

Sorry. I found a configuration parameter labeled "Get password reminder
email for this list?" at

https://www.ietf.org/mailman/options/oauth/{my-email-address}

Unbelievable option... This should not exist.

Takahiko Kawasaki



2014-10-24 18:16 GMT+09:00 Antonio Sanso :

>  hi,
>
>  this is not Oauth@ietf only :)
>
>  regards
>
>  antonio
>  On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki 
> wrote:
>
>  Hello,
>
> As a result of subscribing to oauth@ietf.org, mailmain-ow...@ietf.org
> periodically sends me emails titled "ietf.org mailing list memberships
> reminder" containing my password in PLAINTEXT. It's unbelievably insecure.
>
> Is this happening only to me? How to stop mailmain-ow...@ietf.org from
> sending such emails? It's a terrible joke that this happens for
> OAUTH@ietf.org.
>
> They store our passwords in plaintext in their database, or at least in a
> way for them to decrypt our passwords. One-way hash should be used...
>
> Takahiko Kawasaki
>  ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Password in plaintext in emails from mailmain-ow...@ietf.org

[Takahiko Kawasaki]

Hello,

As a result of subscribing to oauth@ietf.org, mailmain-ow...@ietf.org
periodically sends me emails titled "ietf.org mailing list memberships
reminder" containing my password in PLAINTEXT. It's unbelievably insecure.

Is this happening only to me? How to stop mailmain-ow...@ietf.org from
sending such emails? It's a terrible joke that this happens for
OAUTH@ietf.org.

They store our passwords in plaintext in their database, or at least in a
way for them to decrypt our passwords. One-way hash should be used...

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

Re: [OAUTH-WG] open redirect in rfc6749

[Takahiko Kawasaki]

I think the point is that the registered redirect URI is evil, meaning that
the person who registered the client application is evil. I don't think the
spec can take any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the case
where the scope is valid and consent from the end-user has been obtained.
That is, an attacker would prepare an HTML page at http://attacker.com
which says "Sorry, an error occurred. Please re-authorize this
application." and has a login form that mimics the login form of victim.com.

IMHO, all we can do is to educate people like "Be cautious when you are
requested to login again."

Best Regards,
Takahiko Kawasaki


2014-09-04 4:23 GMT+09:00 Phil Hunt :

> I do not believe this is a flaw specific to 6749. The flaw if any is
> within HTTP itself (RFC7230). Covert redirect is a well known problem.
> There are extensive recommendations that prevent this covered in 6749 and
> 6819.
>
> There is no protocol fix that OAuth can make since it is a trait or
> feature of HTTP.
>
> Instead we’ve made security recommendations which are the appropriate
> response to this issue. Further we published 6819 that provides further
> guidance.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt 
> wrote:
>
> > fine, you're talking security considerations about untrusted clients;
> that's a different use case than the protocol flaw reason why Google would
> not do rfc6749 as written
> >
> > Hans.
> >
> > On 9/3/14, 7:52 PM, John Bradley wrote:
> >> I agree that the error case where there is no UI is the problem, as it
> can be used inside a Iframe.
> >>
> >> However error responses are generally useful.
> >>
> >> OAuth core is silent on how redirect_uri are registered and if they are
> verified.
> >>
> >> Dynamic registration should warn about OAuth errors to redirect_uri
> from untrusted clients.
> >>
> >> For other registration methods we should update the RFC.
> >>
> >> John B.
> >>
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso  wrote:
> >>>
> >>>
> >>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt 
> wrote:
> >>>>
> >>>> Is your concern clients that were registered using dynamic client
> registration?
> >>>
> >>> yes
> >>>
> >>>>
> >>>> Otherwise the positive case is returning a response to a valid URL
> that belongs to a client that was registered explicitly by the resource
> owner
> >>>
> >>> well AFAIK the resource owner doesn’t register clients…
> >>>
> >>>
> >>>> and the negative case is returning an error to that same URL.
> >>>
> >>> the difference is the consent screen… in the positive case you need to
> approve an app.. for the error case no approval is needed,,,
> >>>
> >>>>
> >>>> I fail to see the open redirect.
> >>>
> >>> why?
> >>>
> >>>>
> >>>> Hans.
> >>>>
> >>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
> >>>>>
> >>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <
> hzandb...@pingidentity.com
> >>>>> <mailto:hzandb...@pingidentity.com>> wrote:
> >>>>>
> >>>>>> Let me try and approach this from a different angle: why would you
> >>>>>> call it an open redirect when an invalid scope is provided and call
> it
> >>>>>> correct protocol behavior (hopefully) when a valid scope is
> provided?
> >>>>>
> >>>>> as specified below in the positive case (namely when the correct
> scope
> >>>>> is provided) the resource owner MUST approve the app via the consent
> >>>>> screen (at least once).
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Hans.
> >>>>>>
> >>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
> >>>>>>> hi John,
> >>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley  >>>>>>> <mailto:ve7...@ve7jtb.com>
> >>>>>>> <mailto:ve7...@ve7jtb.com>> wrote:
> >>>>>>>
> >

Re: [OAUTH-WG] Standardized error responses from protected resource endpoints

[Takahiko Kawasaki]

Thank you very much. It is the specification for token_type=bearer
but really useful. I'm ashamed of having forgotten the content of
RFC 6750 although I had read it once before.

Best Regards,
Takahiko Kawasaki

2014-07-30 21:23 GMT+09:00 Brian Campbell :
> Take a look at RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer
> Token Usage" - particularly section 3:
> http://tools.ietf.org/html/rfc6750#section-3 which describes using the
> "WWW-Authenticate" response header field in response to a request with
> an invalid/insufficient/missing/etc token.
>
> On Tue, Jul 29, 2014 at 8:10 PM, Takahiko Kawasaki  wrote:
>> Hello,
>>
>> I have a question. Is there any standardized specification about
>> error responses from protected resource endpoints?
>>
>> "RFC 6749, 7.2. Error Response" says "the specifics of such error
>> responses are beyond the scope of this specification", but I'm
>> wondering if OAuth WG has done something for that.
>>
>> >From error responses, I'd like to know information about:
>>
>>   (1) Usability (active or expired? (or not exist?))
>>   (2) Refreshability (associated usable refresh token exists?)
>>   (3) Sufficiency (usable but lacking necessary permissions?)
>>
>> For example, I'm expecting an error response like below with
>> "400 Bad Request" or "403 Forbidden".
>>
>>   {
>> "error":"...",
>> "error_description":"...",
>> "error_uri":"...",
>> "usable": true,
>> "refreshable": true,
>> "sufficient": false
>>   }
>>
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

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

[OAUTH-WG] Standardized error responses from protected resource endpoints

[Takahiko Kawasaki]

Hello,

I have a question. Is there any standardized specification about
error responses from protected resource endpoints?

"RFC 6749, 7.2. Error Response" says "the specifics of such error
responses are beyond the scope of this specification", but I'm
wondering if OAuth WG has done something for that.

>From error responses, I'd like to know information about:

  (1) Usability (active or expired? (or not exist?))
  (2) Refreshability (associated usable refresh token exists?)
  (3) Sufficiency (usable but lacking necessary permissions?)

For example, I'm expecting an error response like below with
"400 Bad Request" or "403 Forbidden".

  {
"error":"...",
"error_description":"...",
"error_uri":"...",
"usable": true,
"refreshable": true,
"sufficient": false
  }


Best Regards,
Takahiko Kawasaki

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

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

[Takahiko Kawasaki]

Hello,

(1) RFC 6749
  grant_type=authorization_code
  response={"access_token":...}

(2) OpenID Connect Core
  grant_type=authorization_code
  response={"access_token":..., "id_token":...}

(3) Currently being discussed
  (3)-1
grant_type=authorization_code
response_type=id_token  (a new parameter for the token endpoint)
response={"id_token":...}

  (3)-2
grant_type=something_new  (a new value for the token endpoint)
response={"id_token":...}

  (3)-3
response_type=something_new (a new value for the authz endpoint)
grant_type=something_new

However, taking a logical expansion below into account,

(4) Not being discussed yet, but logically possible
  grant_type=password
  response={"id_token":...}

it seems "grant_type" should be treated as a parameter to specify
just a 'flow'. IMHO, what tokens should be included in the response
from the token endpoint should be specified by another different means.
For example, "response_type" (a new parameter for the *token* endpoint)
as suggested by Nat.

Nat> response_type
Nat>   OPTIONAL. A string that expresses what tokens are to be returned
Nat>   from the Token Endpoint. Extension specifications may use this
Nat>   parameter to explicitly expressing the desire to  obtain a
Nat>   particular type of token.

If asked, I would add the following:

  The default value of "response_type" is "token" which means that
  an access token is requested. However, when the following conditions
  are satisfied, the default value is "token id_token".

Condition-1:
  grant_type=authorization_code

Condition-2:
  The authorization code was issued at the authorization endpoint
  with 'openid' scope.

--
Best Regards,
Takahiko Kawasaki



2014-07-24 2:39 GMT+09:00 Mike Jones :

>  You need the alternative response_type value (“code_for_id_token” in the
> A4C draft) to tell the Authorization Server to return a code to be used
> with the new grant type, rather than one to use with the
> “authorization_code” grant type (which is what response_type=code does).
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Wednesday, July 23, 2014 10:33 AM
> *To:* tors...@lodderstedt.net
>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> If we use the token endpoint then a new grant_type is the best way.
>
>
>
> It sort of overloads code, but that is better than messing with
> response_type for the authorization endpoint to change the response from
> the token_endpoint.  That is in my opinion a champion bad idea.
>
>
>
> In discussions developing Connect we decided not to open this can of worms
> because no good would come of it.
>
>
>
> The token_endpoint returns a access token.  Nothing requires scope to be
> associates with the token.
>
>
>
> That is the best solution.  No change required.  Better interoperability
> in my opinion.
>
>
>
> Still on my way to TO, getting in later today.
>
>
>
> John B.
>
>
>
>
>
> Sent from my iPhone
>
>
> On Jul 23, 2014, at 12:15 PM, tors...@lodderstedt.net wrote:
>
>  The "response type" of the token endpoint is controlled by the value of
> the parameter "grant_type". So there is no need to introduce a new
> parameter.
>
> wrt to a potential "no_access_token" grant type. I do not consider this a
> good idea as it changes the semantics of the token endpoint (as already
> pointed out by Thomas). This endpoint ALWAYS responds with an access token
> to any grant type. I therefore would prefer to use another endpoint for the
> intended purpose.
>
> regards,
> Torsten.
>
>
>
> Am 23.07.2014 13:04, schrieb Nat Sakimura:
>
>  IMHO, changing the semantics of "response_type" @ authz endpoint this
> way is not a good thing.
>
>
>
> Instead, defining a new parameter "response_type" @ token endpoint, as I
> described in my previous message,
>
> probably is better. At least, it does not change the semantics of the
> parameters of RFC6749.
>
>
>
>  Nat
>
>
>
> 2014-07-23 12:48 GMT-04:00 Thomas Broyer :
>
> No, I mean response_type=none and response_type=id_token don't generate a
> code or access token so you don't use the Token Endpoint (which is not the
> same as the Authentication Endpoint BTW).
>
> With response_type=code_for_id_token, you get a code and exchange it for
> an id_token only, rather than an access_token, so you're changing the
> semantics of the Token Endpoint.
>
>
>
> I'm not