ication 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:
>
entication 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
out 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,
d 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 outsi
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
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 publi
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
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 w
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 authorizati
-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:/
cification. 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.
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
Aut
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 e
+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 Resp
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 al
RM 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 Ka
`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
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.
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 Kars
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 respon
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 reade
stion-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
e` 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 (vers
; 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 Data
h 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
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 Kawas
erver 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 m
pplication
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
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 wel
al-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 secur
presents 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 resourc
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
ource 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 ot
;>>"iss":"https://as.example-bank.com";,
>>>"aud":"6a256bca-1e0b-4b0c-84fe-c9f78e0cb4a3",
>>>"iat":1532452100,
>>>"_token_data":{
>>> "active":false
>>&
ted "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 Takahik
ociated 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
>
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
ove? 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,
> >
> >
e 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&g
quot; 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
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 a
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
>
>> Nat Sakimura
>>
>> Research Fellow, Nomura Research Institute
>>
>> E: n-sakim...@nri.co.jp
>>
>> T: +81(90)60136276
>>
>> -
>>
>> PLEASE READ:This e-mail is confidential a
ld
> 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 fol
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
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
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 P
lients. 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
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
ject/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 Ka
g 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 Kawas
nguishing "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
y 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
red_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
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 lin
finitions 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
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
> reques
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:* Monda
t;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 re
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
st 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 b
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
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
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
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,
>
.@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
_
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
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 "
x27;m expecting an error response like below with
"400 Bad Request" or "403 Forbidden".
{
"error":"...",
"error_description":"...",
"error_uri":"...",
"usable": true,
"refreshable"
quot;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 authoriza
70 matches
Mail list logo
