Yep, TEEs definitely have limitations that should be managed via
defense-in-depth to prevent things like side channel attacks.
It’s also true that such identity systems based on transmission of raw
digital signatures have been deployed in production today and continue to
gain momentum.
It’s impor
And the draft doesn't have a sufficiently strong statement saying this tech
(which has significant limitations: every TEE has fallen due to side
channels) is needed for relevant application scenarios.
I'm not saying this work shouldn't continue: I'm saying that we need to
ensure we get the privacy
Hi Watson,
Here’s an approach based on TEEs that can in theory create unlinkability
for things like mdocs and SD-JWTs while also conforming to FIPS 140-2/-3.
No new crypto, and PQC-friendly.
https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/
Best,
- Wayne
Richard, it all depends on how you scope the problem.
Hellō uses garden variety crypto and does not have collusion issues and has
true minimal disclosure as Hellō is an abstraction layer and the
original issuer is not exposed.
The internal operation of Hellō prevents any party from viewing user d
Internet-Draft draft-ietf-oauth-resource-metadata-07.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
Title: OAuth 2.0 Protected Resource Metadata
Authors: Michael B. Jones
Phil Hunt
Aaron Parecki
Name:draft-ie
+1 Richard
Mike Prorock
Founder
https://mesur.io/
Grab a meeting!
https://calendar.app.google/aNUcr41gvTAiMUG49
On Mon, Jul 22, 2024 at 5:44 PM Richard Barnes wrote:
> I would observe that any solution based on garden-variety digital
> signature (not something zero-knowledge like BBS / JWP) w
I would observe that any solution based on garden-variety digital signature
(not something zero-knowledge like BBS / JWP) will have problems with
issuer/verifier collusion. One-time tokens and batch issuance don't help.
There is no such thing as SD-JWT with issuer/verifier collusion
resistance. A
On Mon, Jul 22, 2024, 3:30 PM John Bradley wrote:
> I agree that single-use proof keys and batch issuance are a must.
>
> Issuer verifier collusion is admittedly a problem. To address that we do
> need different cryptographic methods.
>
> MDOC also has the same issue.
>
> We should document the
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
I agree that single-use proof keys and batch issuance are a must.
Issuer verifier collusion is admittedly a problem. To address that we do
need different cryptographic methods.
MDOC also has the same issue.
We should document the risk, but short of stopping EUID and mobile driver's
license dep
Dear Oauth,
I'm disappointed to see SD-JWT work continue with inadequate privacy
considerations. The fact is an Issuer can link any showings to
issuance of the credential. This is not foregrounded sufficiently in
privacy considerations, nor do we discuss how to ensure users are
aware. We really ne
11 matches
Mail list logo
