[OAUTH-WG] Re: SD-JWT linkability

[Watson Ladd <[e-mail]>]

On Fri, Dec 20, 2024 at 12:57 PM Pierce Gorman <[e-mail]>
wrote:
>
> Is there an alternative method you have in mind that avoids the
linkability concerns you've outlined?  Would a short paragraph in the
Security Considerations which warns about specific use case
vulnerabilities, and/or perhaps points to a/the suitable alternative be a
way forward?

I don't see why Security Considerations vs. Privacy Considerations changes
it substantively either way. Editorially I think this is the right place.

I don't think warning about specific use cases is a good idea: we can't
anticipate what all the problematic cases will be.
>
> Pierce
>
> CONFIDENTIAL
> -----Original Message-----
> From: Watson Ladd <[e-mail]>
> Sent: Friday, December 20, 2024 12:07 PM
> To: Joseph Heenan <[e-mail]>
> Cc: IETF oauth WG <[e-mail]>
> Subject: [OAUTH-WG] Re: SD-JWT linkability
>
> EXTERNAL EMAIL
>
> On Fri, Dec 20, 2024 at 9:47 AM Joseph Heenan <[e-mail]> wrote:
> >
> >
> >
> > On 19 Dec 2024, at 21:54, Watson Ladd <[e-mail]> wrote:
> >
> > On Tue, Dec 17, 2024, 1:59 PM Joseph Heenan <[e-mail]> wrote:
> >
> >
> > Hi Watson
> >
> > Just to respond to the suggested text:
> >
> >
> > "When disclosures include information easily understood to be
> > identifying, users intuitive view of what they are revealing largely
> > matches the underlying technical reality. In cases where the
> > information being disclosed is not identifying, SD-JWT MUST NOT be
> > used as this confusion leads to users making the wrong choices.
> >
> >
> > This sentence is really hard to make sense of and I don’t think
implementors will understand it. I’m not convinced I understand it even
with the extra context from the threads. I think a MUST NOT is far too
strong too, and saying ’SD-JWT’ in particular must not be used it too
strong as an SD-JWT where everything is disclosed (or no selective
disclosures are present in the issued credential in the first place) is no
different to other credentials formats that don’t have selective disclosure.
>
> I think this is subsumed by the first sentence. When users are disclosing
information that wasn't identifying, but the mechanism involves
transmitting a unique identifier there is a problem.
>
> >
> >
> >
> > Would adding "When users disclose information that is not identifying,
> > e.g. age, the fact that the mechanism in this draft exposes the unique
> > signature of their credential is not obvious. Users could have made
> > different decisions if they understood this. Therefore," in the middle
> > help?
> >
> >
> > I think that makes it easier to understand, but I disagree with the
premise - I believe there are likely ways to describe this to users and
this needs to be properly researched & tested with real people. As I said,
the MUST NOT is too strong regardless - there are likely cases where the
user recognises that tracking like this is possible/inevitable, and
regardless it seems to imply that SD-JWT has worse properties than (for
example) JWT based credentials, which is something we definitely shouldn’t
do.
>
> Then when people have demonstrated that they can mitigate the risk, we
can write a bis. The point is some mitigation needs to be demonstrated. I
want to put text in that someone can show their boss to say "we shouldn't
implement this because we don't have a demonstrated, working mitigation for
the privacy risks that aren't apparent". Do you have alternate ways to
document this issue that will do that?
>
> >
> >
> >
> > Applications cannot assume Verifiers behave properly (RFC
> > 3514) and MUST analyze the consequences for such linkage with each
> > credential that could be used."
> >
> >
> > This ‘MUST’ is practically impossible for some implementors - for
example, it is impractical for a wallet to make this kind of judgement for
each issued credential.
> >
> >
> >
> > Bingo! Wallets that use SD-JWT can't give users the control over their
> > data that we would expect them to have.
> >
> >
> > I don’t think you have shown this very generalised statement is true,
nor that if it was true that it only applies to wallets using SD-JWT.
> >
> > The wallet needs to be aware
> > of how the requests impact user privacy.
> >
> >
> > The wallet doesn’t need to be aware if it is clear to the user from the
context (and perhaps there are other cases too where the wallet doesn’t
need to be aware). The MUST NOT is too strong, and I’m not sure even a
SHOULD NOT would be appropriate.
>
> Somebody has to look out for the user here. In the web its why we call it
a User Agent. If the Wallet isn't going to be capable of doing that, what
will? What is "clear to the user from the context"? In the case of age
verification it really isn't clear what exactly is being revealed.
>
> >
> > Joseph
> >
> >
> > _______________________________________________
> > OAuth mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim