Inline: On Thu, Aug 24, 2023, 6:50 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda > <kristina.yas...@microsoft.com> wrote: > > > > First of all, BBS and SD-JWT are not comparable apple to apple. BBS is a > signature scheme and it needs to be combined with few other things like JWP > or BBS data integrity proof type (https://www.w3.org/TR/vc-di-bbs/) with > JSON-LD payload. While SD-JWT is a mechanism that can be used with any > crypto suite. > > Agreed: the relevant comparison is at the level of systems based on > these formats. That makes it more difficult to have a discussion of > the security of the overall system when these documents go in other > places, and this might not be the right vehicle for it. > I'm not sure if you are referring to OAuth as a transport for credentials or OAuth as a working group with experience designing credential formats. My opinion is that OAuth is a great place for both, but based on some of your comments down thread it seems you might be hoping for something like MLS, or some alternative transports. > > > > Second, how to do batch issuance of the credential (honestly, of any > credential format: not just SD-JWT VCs but also mdocs and JWT-VCs) and > whether it can be done low cost is out of scope of the credential format > (or any of its components) specification itself. Btw when using OpenID4VCI > (an extension of oauth), batch issuing SD-JWTs does not need a blind > signature and I do not know what you mean by exhaustion of the supply of > tokens, there are only access token and refresh token involved in a usual > manner. > > So the issuer knows what it signed? Then it's capable of linking all > presentations to each other because the signature and message is shown > to each verifier even if different commitments are opened each time. > Let's ignore malicious issuers. Malicious verifiers can collude to erode the credential subjects' privacy... See also detecting unwanted location trackers. It's true, it would be nice to prove you can travel on a train without each train station knowing someone is in possession of a public key, or some other correlatable identifier. That's a serious problem. Separately, if each SD-JWT is one use only, > then the issuer needs to be available for refresh once the tokens are > all used, which is a troublesome proposition. Agreed. It's a very different > model from a one time issuance. VC usecases are likely to lend > themselves to things that don't look like oauth in terms of > availability, and as we learned from OCSP running services that must > be up is hard. > At what point is the batch size of single use sd-jwt blocked by the availability of the batch issuance service? Depends on the use case probably. > I want to be clear: the threat model that's applicable to real people > across the web has the issuer working with data sent to the verifiers > to try to determine what the holder did. The issuer knows (or predicts) what the subject did, and the subject is not always the holder. The holder discloses claims about subjects to the verifiers. The verifier learns what the holder discloses about subjects and which issuer made which claims about subjects. The holder could be a sybil, but that's often mitigated with globally unique identifiers, or identity proofing. The holder could be a service identity, running in a mobile device, or a cloud function. In general, holder is client, issuer is AS, and verifier is RP. It sounds like the threat model you are talking about is one where verifiers are compelled by law or profit motive to share "what they know", and the any holder disclosing claims about subjects to a verifier increases "what they know". Is that right? Can you help me understand the proposed mitigations if the model summary is accurate? This is extremely unlike real > world credential presentation where e.g. showing my drivers license to > a bouncer doesn't mean the DMV knows what bar I went to. This is referred to as the "phone home" problem. It manifests in at least 2 places in w3c verifiable credentials: 1. credential refresh, where the holder goes back to an issuer for credentials about subjects that are about to expire, or have had their status change. 2. credential status checks, where the verifier checks with the issuer the credential is not revoked 1. is mitigated with clever batching to some degree. 2. is mitigated with "status lists" that have heard privacy or methods that don't reveal the specific credential the verifier is checking on, to the issuer. The DMV can still buy the data from all the bars... https://www.congress.gov/bill/117th-congress/house-bill/7900/text > We have very > clear guidance in RFC 8890 from the IAB that we are supposed to take > these risks seriously, and privilege them over other considerations. > Agreed, and of all the places at IETF that could be taking this seriously, OAuth probably has the most relevance to the challenges. > The applications to Digital Wallets when combined with a push for Age > Verification are exactly the sort of thing where people will make > expedient choices (use SD-JWT with what's being issued) in a way that > creates an enormous privacy risk that is not obvious to end users. > > Lets focus on describing the threat model, are we modeling threats specific to age verification or any 3 party knowledge graph system with edges made of signed claims by issuers? > Sincerely, > Watson Ladd > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
