Thanks, this looks like a good and reasonable conclusion.
Allowing for extensions is okay. Adding X.509 support, and this isn't
exactly a backwards compatibility or bridging kind of feature, as an
OAuth WG document would not be appropriate.
Vladimir Dzhuvinov
On 27/02/2025 17:41, Chri
t;
https://datatracker.ietf.org/doc/html/draft-bertola-dns-openid-pidi-architecture-01
"OpenID Connect DNS-based Discovery"
https://datatracker.ietf.org/doc/html/draft-sanz-openid-dns-discovery-01
Vladimir Dzhuvinov
On 21/01/2025 19:15, Phillip Hallam-Baker wrote:
As some of yo
access the protected
resource.
"insufficient_scope" should be perfectly fine for "RAR-red" tokens.
The error description is the token not having enough privileges, in the
general sense.
Do you need to communicate additional error info back from the resource?
Vladimir
resubmit without
changes, just as it's okay to disagree on a particular adoption. I get
it that the topic of PIKA feels contentious.
Vladimir Dzhuvinov
On 03/09/2024 13:47, Rifaat Shekh-Yusef wrote:
All,
As per the discussion in Vancouver, this is a call for adoption for
the *Proof of Is
Pieter
*From:*Vladimir Dzhuvinov / Connect2id
*Sent:* Friday 13 September 2024 07:50
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Re: Call for adoption - First Party Apps
I read the proposed spec and it's evident substantial work has gone
into it. Congratulations for this.
How does the 1s
take care of this?
Vladimir Dzhuvinov
On 03/09/2024 13:46, Rifaat Shekh-Yusef wrote:
All,
As per the discussion in Vancouver, this is a call for adoption for
the First Party Apps draft:
https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/
Please, reply on the mailing lis
Interesting draft. Having standard defined scopes for the most common operations of the underlying protocols is crucial, as Lisa points out. In OpenID Connect this was indispensable in making the whole thing complete, useful and interoperable. But where should these scopes get defined, if this is a
+1 in support for publication.
Vladimir Dzhuvinov
On 18/05/2024 08:45, Phillip Hunt wrote:
+1. I agree this is ready.
Phil
On May 17, 2024, at 1:35 PM, Giuseppe De Marco
wrote:
+1 for publication
Il giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef
ha scritto:
All
I have a question about the parameters:
resource_signing_alg_values_supported,
resource_encryption_alg_values_supported,
resource_encryption_enc_values_supported.
I'm not sure how to interpret "content". Where the algorithms, if
advertised, get to apply. Is this something that resources /
ap
+1 for the adoption so we can explore this as a WG document
+1 to Brian's comment to consider the application to tokens in general
(unless the authors have plans for JWT / CWT specific features)
Vladimir Dzhuvinov
On 03/10/2023 00:10, Brian Campbell wrote:
I support adoption.
I do
I support adoption.
Vladimir Dzhuvinov
On 23/08/2023 20:01, Rifaat Shekh-Yusef wrote:
All,
This is an official call for adoption for the *Protected Resource
Metadata* draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
Please, reply on the mailing list and let us
+1 in support for this complementary draft.
Vladimir Dzhuvinov
On 26/05/2023 16:55, Oliver Terbu wrote:
Dear all,
I hope this email finds you well. I am writing to introduce
"SD-JWT-based Verifiable Credentials with JSON payloads” (SD-JWT VC):
https://datatracker.ietf.org/doc/draft-
Hi Tobias,
OAuth 2.0 and OIDC originally have a model where the client metadata is
made to match the server's requirements and supported algorithms.
This looks roughly like this:
* The server has its metadata published at the well-known URL.
* The client developer examines the server met
+1 in support for adoption.
Vladimir Dzhuvinov
On 15/11/2022 16:43, Rifaat Shekh-Yusef wrote:
All,
During the IETF meeting last week, there was a strong support for
the adoption of the following document as a WG document:
https://datatracker.ietf.org/doc/draft-kasselman-cross-device
could be none (i.e.
no PKCE) or S256, in the latter case a client will need to explicitly
opt out of it, but how exactly?
From the perspective of an OAuth 2.1 deployment it would be S256.
Vladimir Dzhuvinov
On 09/10/2022 02:33, Dima Postnikov wrote:
Hi Vladimir.
Client registration
Hi Brock,
Right, so it's already happening :)
My honest preference is to give people a standard code_challenge_method
client reg parameter for this job and eliminate guesswork.
~ Vladimir
Vladimir Dzhuvinov
On 08/10/2022 05:38, Brock Allen wrote:
> Has anyone faced the issue h
in the
OAuth 2.1 spec for code_challenge.
Another spec that deals with PKCE is the OAuth BCP, but to me that's not
a optimal place to define a new parameter.
Vladimir Dzhuvinov
On 08/10/2022 04:31, Dima Postnikov wrote:
Hi Vladimir,
Similar issue exists in CDR (Australian Open Bank
RFC 8414 defined the code_challenge_methods_supported metadata for
servers. It would be useful if deployments had a corresponding parameter
for the clients.
https://www.rfc-editor.org/rfc/rfc8414
~ Vladimir
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic
/datasheet#dpop
Vladimir Dzhuvinov
On 11/08/2022 00:39, Rifaat Shekh-Yusef wrote:
All,
As part of the shepherd write-up for the *DPoP* document, we are
looking for information about implementations of this draft.
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, reply to this
new string parseable and thus solve the case.
Having a std DPoP token type URI would be nice for clients to hint to
the AS that the subject/actor_token is a combination of DPoP proof and
access token.
Vladimir
Vladimir Dzhuvinov
On 18/07/2022 21:46, Brian Campbell wrote:
While there are potent
DPoP proof. I don't think that
could have been anticipated at the time when the exchange spec was
devised. And the token exchange spec is not explicit in prohibiting
extensions.
Vladimir
Vladimir Dzhuvinov
On 18/07/2022 17:03, Warren Parad wrote:
I agree this is a problem, but as I see it
've come to the
conclusion that a spec change of some sort is the proper way to solve
this. The proposed solution has no effect on DPoP core and it preserves
the existing token exchange semantics.
Vladimir
Vladimir Dzhuvinov
On 25/06/2022 15:23, Vladimir Dzhuvinov wrote:
Hi Warren,
The
uiring the client to
use the same JWK with both ASes. Another possibility is to include the
DPoP proof in the form parameters alongside the subject_token, but this
will require a spec change.
Vladimir Dzhuvinov
On 25/06/2022 13:33, Warren Parad wrote:
What's the flow here? Assuming we a
,
Vladimir
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1 for adoption
Vladimir Dzhuvinov
On 26/04/2022 13:46, Rifaat Shekh-Yusef wrote:
This is a call for adoption for the *Step-up Authentication* document
https://datatracker.ietf.org/doc/draft-bertocci-oauth-step-up-authn-challenge/
Please, provide your feedback on the mailing list by *May 10th
Hello Hannes,
The RAR spec has been stable for some time now and received production
implementations in several different industries.
https://connect2id.com/products/server/docs/datasheet#rar
~Vladimir
--
Vladimir Dzhuvinov
On 06/04/2022 16:46, Hannes Tschofenig wrote:
Hi all,
I am
I support DPoP publication
--
Vladimir Dzhuvinov
On 28/03/2022 15:01, Rifaat Shekh-Yusef wrote:
All,
As discussed during the IETF meeting in *Vienna* last week, this is a
*WG Last Call *for the *DPoP* document:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/
Please, provide your
Given the suggested protocol for step up (I just watched the talk in
Vienna, thanks Vittorio & Brian) - how could an RS signal that it simply
wants the end-user re-authenticated, without being concerned about the ACR?
Vladimir
--
Vladimir Dzhuvinov
smime.p7s
Description: S/
+1 in support for publication.
The Nimbus JWT lib was recently updated to match the 01 spec with the
hash alg in the URN.
Vladimir Dzhuvinov
On 21/02/2022 15:12, Rifaat Shekh-Yusef wrote:
All,
Mike and Kristina made the necessary changes to address all the great
comments received during
ossibility?
~Vladimir
Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume
it is SHA-256, but it should either say that is the only algorithm
allowed or perhaps encode the hash algorithm into the URI. Otherwise
the value is
+1 in support for a jkt URI RFC
Vladimir Dzhuvinov
On 02/02/2022 16:50, Mike Jones wrote:
Thanks Rifaat,
I support publication of the specification.
-- Mike
*From:* OAuth *On Behalf Of * Rifaat Shekh-Yusef
*Sent:* Wednesday, February 2, 2022 4:19 AM
*To:* oauth
*Subject:* [OAUTH-WG] WGLC
+1 in support for adoption
Vladimir Dzhuvinov
On 13/01/2022 16:26, Rifaat Shekh-Yusef wrote:
All,
This is a call for adoption for the *JWK Thumbprint URI* draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-jwk-thumbprint-uri/
Please, provide your feedback on the mailing list by *Jan
sort of a proprietary extension.
Vladimir
Vladimir Dzhuvinov
On 11/12/2021 12:35, Nikos Fotiou wrote:
Hi,
I have a use case where a resource server is protected and can only be accessed if a JWT is presented. Is
there any way for the server to "indicate" the "expected"
ntrospection response, it must be "DPoP"?
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-03#section-6.2
Vladimir
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ie
Thank you Robert. We'll consider the proposed change to the must
language in the privacy section.
Vladimir Dzhuvinov
On 28/06/2021 17:14, Robert Wilton via Datatracker wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-oauth-jwt-introspection-response-1
The spec is fine, we've had it implemented for some time now and support
its publication.
+1 to Brian's comment. I suppose it suffices to say the iss parameter is
redundant when JARM is used as JARM provides the same countermeasure. I
found the normative text about what JARM allows or disallow
uth-jwt-introspection-response/blob/master/draft-ietf-oauth-jwt-introspection-response.xml
Vladimir
Vladimir Dzhuvinov
On 04/02/2021 16:40, Roman Danyliw wrote:
Hi! Rob!
-Original Message-
From: OAuth On Behalf Of Robert Wilton via
Datatracker
Sent: Thursday, February 4, 2021
Supported by
* the Connect2id server
* the open source OAuth 2.0 / OIDC SDK, and also picked up by some
downstream security frameworks and projects
https://connect2id.com/blog/pushed-authorisation-request-in-oauth-sdk
Adoption of PAR seems to be progressing rather well, which I find
r refresh tokens?
>
> Regards,
> Andrii
>
>
> On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Hi Warren,
>
> On 08/02/2021 17:59, Warren Parad wrote:
>> None of that justified explicitly stating that refr
he ABNF.
>
> Or, we could update the definition of the Bearer header in the
> upcoming OAuth 2.1 specification.
>
> Are there other options?
>
> — Justin
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://ww
ools.ietf.org/html/rfc6750>].
> The methods of managing and
>validating these authentication credentials are out of scope of this
>specification.
Vladimir
>
>
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data and complete your authoriz
zer that was run on this payload as input
> to JWT generation also removed the spaces in the scope string? I seem
> to be having some unexpected behavior from my local tooling, but it is
> looking like the claims set from the example HTTP payload lists
> "scope":"re
t;
> Regards,
> Andrii
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
lication/token-introspection+jwt"?
>>> >
>>> > I expect there will be no differences, right?
>>> >
>>> > If so, I suggest to
>>> > • replace "a resource server" b
ging the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>1. Re: Tenancy in OAuth (Justin Richer)
>2.
t; +31(0)641495324
>>
>> mendix.com <http://mendix.com/>
>>
>> ** <http://www.mendix.com/>
>> * *
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
256 and calling it a day (and defining other
> hashes in the future when SHA256 is broken), but that’s not a hill I
> care to die on.
>
> — Justin
>
>> On Dec 14, 2020, at 4:27 PM, Brian Campbell
>> > <mailto:bcampbell=40pingidentity@dmarc.ietf.org>> wrote
__
>> > OAuth mailing list
>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/oauth
>> > __
n concern here is the effort of doing DPoP in a
>>> browser versus the limited gains. It may also give a
>>> false sense of security.
>>>
>>>
>>>
>>> With all this said, I believe that the AS can lock down
>>>
ec-fetch-mode: navigate
> sec-fetch-site: cross-site
> sec-fetch-user: ?1
> /
>
>
> Philippe
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited. If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Support with both hands!
Vladimir
On 08/12/2020 14:50, Rifaat Shekh-Yusef wrote:
> All,
>
> This is a call for adoption for the following AS Issuer Identifier in
> Authorization Response as a WG document:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>
> Please, p
If people have articulated a need to have an invalid_redirect_uri error
for the PAR endpoint, then let's register it properly. Rifaat says
there's still time to do this.
I'm also okay with using the general invalid_request code for this. In
this case a sentence, next to the current example, spelli
may be good to say "MUST NOT" as you suggested.
>
> Taka
>
> On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Re Case 1: When JARM is used:
>
> A colleague pointed me to the following statement in
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
>
the reply. Would be great if you can share your insights on
> how those parameters are being used.
>
> I could not find any public docs explaining their usage, so thought
> they probably are being used by the Google applications by themselves.
>
> Thanks!
>
>
> On Wed, Nov 4
onal parameters as a
> violation of the RFC6749?
>
> Thanks!
> -Alex
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
?
>
> 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 Rega
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 fir
Hi Karsten,
Thanks for the write up. I would like to suggest the name
authorization_response_iss_parameter_supported, instead of
iss_parameter_supported. To make it explicit and unambiguous that it's
about the authZ response.
Vladimir
On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote:
>
> He
question is "Should `scope` be omitted?" I guess that the
> conclusion will affect the official conformance suite.
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
>
>
> On Tue, Sep 22, 2020 at 5:59 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.co
The mTLS vs DPoP was good in articulating how the two specs are alike,
how they differ and which particular type of app they are meant to serve.
I'm saying this as a person who is generally allergic to technical
podcasts :)
Maybe every RFC that comes out of this WG should have a podcast link at
t
A conforming implementation and looking forward to the final spec :)
https://connect2id.com/products/server/docs/datasheet#access-token-encoding-jwt
On 17/09/2020 15:55, Hannes Tschofenig wrote:
> Hi Vittorio, Hi all,
>
> I am working on the shepherd writeup for
> and you can find the latest ve
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 param
onfidential 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 d
On 10/08/2020 11:28, Neil Madden wrote:
> Thanks Vladimir,
>
> Responses below
>
>> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov wrote:
>>
>> Hi Neil,
>>
>> I definitely like the elegance of the proposed alg for JOSE, it provides
>> something that
Hi Neil,
I definitely like the elegance of the proposed alg for JOSE, it provides
something that isn't currently available in the various classes of algs
made standard in JOSE.
I also wanted to ask what's happening with AES SIV for JOSE, if there's
traction / feedback / support there as well?
ht
On 21/07/2020 18:43, Torsten Lodderstedt wrote:
>
>> On 21. Jul 2020, at 17:40, Vladimir Dzhuvinov
>> wrote:
>>
>>
>>
>> On 21/07/2020 17:47, Justin Richer wrote:
>>>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov
>>>> wrote:
&g
On 21/07/2020 17:47, Justin Richer wrote:
>> On Jul 19, 2020, at 1:04 PM, Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>>
>> On 18/07/2020 17:12, Justin Richer wrote:
>>> I think publishing supported “type” parameters isn’t a bad idea, and i
.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is s
ke
> better decisions about what to put in that string.
I'm still on the fence with that but I do see your argument.
Vladimir
>
> — Justin
>
>> On Jul 17, 2020, at 2:13 PM, Vladimir Dzhuvinov
>> wrote:
>>
>>
>> On 17/07/2020 17:38, Justin Ric
On 17/07/2020 17:38, Justin Richer wrote:
> And all that brings me to my proposal:
>
> 4) Require all values to be defined by the AS, and encourage specification
> developers to use URIs for collision resistance.
>
> So officially in RAR, the AS would decide what “type” means, and nobody else.
+1
Vladimir
On 15/07/2020 20:54, Dick Hardt wrote:
> +1
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef
> mailto:rifaat.s.i...@gmail.com>> wrote:
>
> All,
>
> This is a *call for adoption* for the following *OAuth 2.1*
> document as a WG document:
> https://www.ietf.org/id
On 09/07/2020 19:06, Dave Tonge wrote:
>
> If a particular implementation wants to allow a two stage transaction,
> they can simply pass some reference to the first auth in the
> subsequent RAR auth flows, e.g.
>
> First flow, a user grants access with the simple scope of
> "make_payments", the ac
On 09/07/2020 11:07, Neil Madden wrote:
>
>>
>> An AS is always free to implement the 2 step solution that you
>> proposed and indeed it could be easier to implement with RAR in the
>> manner you described, but I don't think it should be the prescribed
>> approach.
>
> How can an AS implement this
I find 03 well structured, well written and it shows that a lot of
thought and work has gone into it.
If this is a formal call for adoption - I support it.
> - defined new client type - credentialed clients - a client that has
> credentials, but the AS has not confirmed the identity of the clien
On 06/07/2020 19:32, Neil Madden wrote:
> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have
> some time, and I have a few comments.
>
> An assumption in the draft appears to be that the client knows ahead
> of time what it wants to gain access to and can describe it in detail.
>
On 08/06/2020 12:15, Daniel Fett wrote:
> That would be the safe implementation, but I was wondering if
> prescribing this is a good choice for an ecosystem.
Postfix vs infix:
If we reason about the common ways ASes (as web apps) get deployed, then
(perhaps) it will become obvious which method is
Thanks for laying out the solutions so neatly.
We would prefer #2 the "dynamic" solution because it wouldn't require us
to do any changes. I've had the impression that the unexpected
code_verifier case was somehow covered as an error in RFC 7636 but
checked the spec now and apparently it isn't.
V
banking is for having
> the AS display the "consumer-brand" logo to the RO in the consent screen.
>
>
> >> On 22 May 2020, at 08:52, Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
> >>
> >> With that said it makes sense to
nt set would be needed to determine the set
> of endpoints to be used by a certain client.
>
> On the conceptual side, I’m asking myself how the complete process is
> supposed to work. Who is deciding what issuer/endpoint set combination to
> use. I assume in an open banking scenario, th
prefer the simpler
> option of just using a single authorization endpoint. Supporting the
> new spec would allow a better UX though so there’s advantages to
> client to do so.
>>
>> Speaking of mTLS, I'm not sure how the "mtls_endpoint_aliases" can be
>> sensibly combine
Hi Dave,
In the absence of such a "multi-brand" spec we have tackled this issue
in the past by letting the "brand" be encoded in the client_id. An
alternative scenario is to do a "brand" lookup by client_id. Then let
the AS render the "branded" authZ endpoint.
You're probably aware the mTLS spec
t;> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.iet
I get your frustration with PKCE. It would be a bad policy and example
to burden compliant ASes with additional stuff just because a few AS
implementations are not complying with the spec. It's not fair and can
end up creating all sorts of bad incentives in future.
Vladimir
On 22/04/2020 10:29, N
Nat, John, thanks for updating the JAR spec. I just reviewed it, in
particular the authz request and the security considerations sections.
Choosing to make client_id (as top-level parameter) mandatory for all
cases, even for those when it can be readily extracted from the JWT,
makes the job of impl
On 16/04/2020 10:10, Dominick Baier wrote:
> *iat vs nbf*
> What’s the rationale for using iat instead of nbf. Aren’t most JWT
> libraries (including e.g. the .NET one) looking for nbf by default?
Developers often tend to intuitively pick up "iat" over "nbf" because it
sounds more meaningful (my p
organization. Do not click links or open attachments unless you
>> can confirm the sender and know the content is safe.
>>
>>
>> I was hoping to get to a rough consensus in support of the idea
>> before coming up with a name that everyone will hate :
I'm all for that.
I suppose you have already thought of a suitable name? :)
Vladimir
On 14/04/2020 23:08, Brian Campbell wrote:
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity
> protected, and (for confidential cl
terial 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 attachment
urity properties it would be quite difficult to
>> specify safely..
>> > >>
>> > >> Query paramaters can still be sent outside the JAR,
>> but if they are in
>> > >> the OAuth registry the AS MUST ignore them.
>> I'm wondering if the following conflicts in "JWT
>> Response for OAuth Token Introspection" (draft 8) have
>> already been pointed out.
>> >>
>> >> RFC 8707 (Resource Indic
y has RFC 8418 as the reference next to
> code_challenge_methods_supported where it should be RFC 8414.
>
> On Tue, Feb 11, 2020 at 11:43 AM Vladimir Dzhuvinov
> mailto:vladi...@connect2id.com>> wrote:
>
> Fantastic, we now have "code_challenge_methods_supporte
Fantastic, we now have "code_challenge_methods_supported" defined for AS
metadata and it's a MUST. Long overdue.
Vladimir
On 10/02/2020 20:14, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the We
having to index all
request_uris individually. I mentioned this before.
I really wonder what the reasoning of the IESG reviewers was to insist
on no params outside the JAR JWT / request_uri.
I'm beginning to realise this step of the review process isn't
particularly transparent to
On 14/01/2020 04:25, Justin Richer wrote:
> It would’ve been nice if JWK could’ve agreed on a URL-based addressing
> format for individual keys within the set, but that ship’s sailed.
For querying / selecting JWKs from a set this would have been a useful
addition to the spec.
But I don't see how
On 14/01/2020 06:46, Benjamin Kaduk wrote:
> On Mon, Jan 13, 2020 at 12:32:41PM -0500, Justin Richer wrote:
>> To be clear, I’m not saying we suggest a particular form, and I agree that
>> we shouldn’t specify that “it’s a JWT” or something of that nature. But if
>> we call the result of PAR “thi
ng that you had to do an HTTP lookup on the request_uri, but I
> believe that’s been backed off now and made conditional.
That was precisely my point.
Vladimir
> — Justin
>
>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov
>> mailto:vladi...@connect2id.com>> wrote:
>
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
>>>>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>>>> > • Request Object is defined to be a JWT containing
>>>>>>> all the authorization request parameters. (Section 2.1)
>>>>>>> >
>>>>>>> > There is no need for this requirement to support
>>>>>>> interoperability, as this is internal to the AS. It is also
>>>>>>> inconsistent with the rest of JAR, which avoids attempting to
>>>>>>> define the internal communications between the two AS endpoints.
>>>>>>> Worse, this restriction makes it harder for the authorization
>>>>>>> endpoint to leverage validation and other work performed at the
>>>>>>> PAR endpoint, as the state or outcome of that work must be
>>>>>>> forced into the JWT format (or retrieved via a subsequent
>>>>>>> service call or database lookup).
>>>>>>> >
>>>>>>> > –
>>>>>>> > Annabelle Richard Backman
>>>>>>> > AWS Identity
>>>>>>> >
>>>>>>> > ___
>>>>>>> > OAuth mailing list
>>>>>>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>
>>>>>>>
>>>>>> ___
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> */CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>>> privileged material for the sole use of the intended recipient(s).
>>>>> Any review, use, distribution or disclosure by others is strictly
>>>>> prohibited. If you have received this communication in error,
>>>>> please notify the sender immediately by e-mail and delete the
>>>>> message and any file attachments from your computer. Thank you./*
>>>
>>> */CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s).
>>> Any review, use, distribution or disclosure by others is strictly
>>> prohibited.. If you have received this communication in error,
>>> please notify the sender immediately by e-mail and delete the
>>> message and any file attachments from your computer. Thank you./*
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ardt for bringing this need to my attention as we were finishing
> the JWT spec.)
>
>
>
> -- Mike
>
>
>
> *From:* OAuth <mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley
> *Sent:* Friday, January 10, 2020 2:1
1 - 100 of 221 matches
Mail list logo
