All,
This is an official call for adoption for the *Proof of Issuer Key
Authority (PIKA)* draft:
https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
Please, reply *on the mailing list* and let us know if you are in favor or
against adopting this draft as WG document, by *June 24th*.
Regard
While I'm generally supportive of the goals of this draft, I have issues with
the mechanisms proposed. Therefore, I believe that more working group
discussion is needed before adoption.
If I were to do something along these lines, I would not use "x5c". Other than
for TLS certificates, the OA
[ as an individual ]
+sd-jwt is requested to be registered in this document:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-08#name-structured-syntax-suffix-re
+cwt is requested to registered in this document:
https://datatracker.ietf.org/doc/html/draft-ietf-rat
Hi Mike,
The intent here is to follow exactly the same security model as current
HTTPS-based OP key discovery mechanisms, e.g., OpenID Connect Discovery.
With those mechanisms:
1. The only way the issuer is authenticated is via a certificate presented
in HTTPS.
2. The only aspect of the URL that
Please, consider volunteering for 2024 NomCom to help with selecting the
next round of IETF leaders.
Regards,
Rifaat
---
The IETF tools development team identified an error in the interface
between the IETF registration system and the datatracker that mistakenly
marked people as volunte
Hello Everybody,
OAuth Status Assertions replaces OAuth Status Attestations and it is
published here:
https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/
Therefore here its html preview:
https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-00.html
Compared to
Hi,
I appreciate the introduction of PIKA, which demonstrates a commitment to
addressing current challenges. However, I have identified some key areas of
concern that need attention:
1. The current documentation lacks clarity regarding the number and scope
of cryptographic keys, particularly in t
Hi Giuseppe,
To be blunt, solving the use cases we're talking about with OpenID
Federation is like doing surgery with a chainsaw. You might achieve the
intended goal, but the results will be messy.
The trust model we are addressing is one that already exists: A JWT is
issued by an issuer identif
In case it's not clear from other messages in this thread: I think this
draft should be adopted. It solves several pressing use cases, with the
minimal amount of complexity needed.
--Richard
On Mon, Jun 10, 2024 at 7:47 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is an official call for adopt
As both I and Giuseppe pointed out, the requirement for applications to use and
understand X.509 certificates means that the draft is way beyond the minimum
complexity needed.
Eliminate application-level X.509 (which is an anachronism that OAuth and JOSE
have moved away from), and I’ll support
The applications we're talking about are **already** doing X.509 when they
make HTTPS connections. It's not a new requirement. The only thing we're
doing is using the certificate for JWT instead of HTTPS.
--RLB
On Mon, Jun 10, 2024 at 11:15 PM Michael Jones
wrote:
> As both I and Giuseppe poi
We all know that TLS certificates are handled by platform layers used by
applications and not the applications themselves. There is no code that
understands X.509 certificates in most applications that use TLS. They are not
equivalent in complexity.
The draft would require adding code directl
On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
wrote:
>
> We all know that TLS certificates are handled by platform layers used by
> applications and not the applications themselves. There is no code that
> understands X.509 certificates in most applications that use TLS. They are
> not equiva
This whole problem did not need to happen. When the federation spec was
being created I asked them not to deviate unnecessarily from pki. But the
very guys that are on this thread told me that they were not a pki and so
there was no reason for them to follow existing rules. This is entirely a
probl
Watson, you wrote "An X509 certificate is the only way to link a DNS name to a
key at a given point in time". However, that's not true. For over a dozen
years, OpenID Connect has used a .well-known endpoint rooted at the issuer URL
from which keys are retrieved (using the jwks_uri parameter) t
On Mon, Jun 10, 2024, 9:33 PM Michael Jones wrote:
>
> Watson, you wrote "An X509 certificate is the only way to link a DNS name to
> a key at a given point in time". However, that's not true. For over a dozen
> years, OpenID Connect has used a .well-known endpoint rooted at the issuer
> URL
16 matches
Mail list logo
