Re: Binding credentials to publicly accessible repositories

I think this thread illustrates the point I've been trying to make about
delegated authorization and the Cruise Ship Use Case
https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0031.html

For convenience and simplicity, the Subject may want to sign an
authorization that does not include the VC as long as the authorization and
the VC share a trusted identifier of the Subject _and_ "calling home" for
the VC is not a concern of the Subject in that context.

For example, using the current actors:

   - The insurance company, as Issuer, checks a Subject's driver's license
   photo and puts the license number, StateID, in the proof of insurance VC
   and keeps the VC, protected, on-line.
      - If the Subject has a DID, Issuer could use the DID instead of the
      StateID, after an authentication challenge, no photo check required
   - The Subject, in response to a request by some authority (the motor
   vehicle registry) for the proof-of-insurance VC, issues an access
   authorization (token) to the registry as Verifier.
      - The Verifier "expects" a StateID or DID to be part of the VC they
      will receive.
      - The authorization is a link to the VC being protected on-line by
      the insurance company.
      - The authorization (token) is cryptographically protected in a way
      that is trusted by the Issuer
   - The Verifier uses their authorization token to access the linked VC
   directly from the Issuer
      - If the VC has a StateID, the Verifier _may_ choose to check a
      driver's license photo
      - If the VC has a DID, the Verifier _may_ choose to issue an
      authentication challenge.

In the case of motor vehicle registration, the Verifier doesn't check who
asked for the license plate at the time of issue. They are confident that,
if the speed cameras record an infraction, they will be able to hold the
Subject of the request accountable at that time. It will be up to the
Subject to document that they lent the car to their offspring.

In the case of the cruise ship, the Verifier of the VC is actually a
delegate of the cruise operator:

   - The request for a verifiable presentation may be made by the cruise
   operator or by their verification service provider
   - The access authorization token may be presented to the Issuer by
      either the cruise ship operator or their delegated service provider.
      - The boarding pass is issued to the Subject by the cruise operator
      based on the service provider's statement of verification and a check of
      the cruise operator's database for the Subject where the subject is
      referenced either by StateID or a DID.
   - When the Subject attempts to board, they need to authenticate
      - The Subject presents their boarding pass
      - The cruise operator either checks the driver's license photo or
      issues a challenge to the DID.

Note that whether or not the VC identifies the Subject by StateID or DID,
the Subject never holds the VC itself. This enables delegation so that the
cruise ship operator does not have to process the complex context around
verification or do any cryptography related to the Subject's issuer. The
cruise ship operator has only one trust relationship, with the Verifier
service. The Verifier service actually tracks a myriad of business rules
that depend on the VC standard for efficient processing.

In summary, efficiency, convenience, and security are enhanced through the
separation of concerns between control of the VC and it's possession as in
https://github.com/w3c-ccg/community/issues/195 .

As for privacy, it's up to the Subject to decide whether to "hold" a copy
of their VC. If they are concerned about the Issuer being contacted by the
Verifier or if they think the Issuer will be off-line when needed, then the
Subject will authorize themselves and grab a copy of the VC to hold. If
that VC uses a StateID or a DID, then the Subject will need to authenticate
accordingly as part of the presentation of that VC.

- Adrian

On Fri, Jul 30, 2021 at 5:56 PM Joe Andrieu <joe@legreq.com> wrote:

> On Fri, Jul 30, 2021, at 11:58 AM, Leonard Rosenthol wrote:
>
> > To my reading of your design, the party who signs the tamper-proof
> mechanism is attesting the binding between the elements of the PDF.
>
> >
>
> Not just PDF – but yes, I agree completely with this statement.
>
>
>
> > does the verifier trust the signer as a valid authority for that
> attestation?
>
> >
>
> Right question, however, while the verifier trusts the signer to make
> attestations of this nature, it has no way of knowing if it can make this *
> *specific** attestation.
>
>
> How could you trust an issuer to make attestations of this nature, but not
> trust them to make a specific attestation? If you trust the DMV for
> attestations about driver's licenses, how would you know to NOT trust them
> for a specific driver's license? Seems like the trust factor involves both
> the authority and the scope of trusted attestations. Within those, e.g.,
> driving privileges, it is only the DMV that has the authority to decide
> which specific driver gets what specific attestations. That's sort of the
> point, the verifier doesn't have any special information about specific
> attestations other than what is in the VC (and perhaps in associated DID
> Documents or certificates)
>
> I think we may be talking past each other on that point.
>
> > Because the whole goal of your approach is to allow arbitrary VCs to be
> attached to a PDF
>
> >
>
> Yes and no.  It’s about allowing for VCs that are connected to this asset
> in some way to be attached to it.
>
>
> The connections are only as strong as the party asserting the connection.
> Hence the need to have a well-known identifier for the signing party.
>
> > If someone takes a VC from one PDF and binds it to another, that's a
> fine use case.
>
> >I may take a driver's license VC that I get from a insurance application
> and in turn embed that VC in a proof of insurance statement.
>
> >
>
> But you couldn’t be able to put **my** driver’s license VC in **your**
> proof of insurance.
>
>
> Ah... my apologies. I was sloppy with my pronouns. I'll restate in hopes
> of being clearer:
> *An insurer may take a driver's license VC that it gets from a insurance
> application and in turn embed that VC in a proof of insurance statement as
> a PDF they sign.*
>
> If that insurer put *your* driver's license in a *their* proof of
> insurance, then they are making a claim that you have insurance, presumably
> offered by them. That's totally valid and a completely different claim than
> if they put my driver's license in a claim that I have insurance.
>
> What would violate integrity is if a random party, BadActorJoe, could
> attach a driver's license to a PDF "from that insurance company". Only the
> insurance company should be able to make that assertion.
>
> I think this boils down to the fact that your tamper-proof attestation is
> only as good as your identification of the signer of that attestation.
> Signatures that can't be tied to a particular party, such as the DMV or
> Allstate Insurance, don't attest to anything at all other than the fact
> that the content hasn't changed since some random person created it (which
> could be a bad actor). At most you might manage pseudonymous session keys
> where all you are confirming is that the signature is from a party that
> controls the same crypto as was used in this session establishment. In that
> case, only the information from that session can be considered connected,
> unless some other forms of identity proofing have taken place. In which
> case that identity proofing is how you are establishing the trust for that
> pseudonymous identifier. So, we still have an allow-list: you won't trust a
> different cryptographic identifier for a message sent in that session.
>
>  > The validity of the application's binding is dependent on the
> authority of the party binding that application to the VC (presumably the
> applicant, subject to assurances).
>
> >
>
> Again, I agree.  But there is no way to know whether that applicant has
> the authority to make that specific claim.
>
>
> Ummm... their presentation of that VC is an assertion of their authority
> just as fully as handing a driver's license to a cop when pulled over is an
> assertion that the DL is the driver's. It doesn't mean that it is. They
> could have stolen it. Rather, it means that the physical person how handed
> the card over is claiming that it is theirs. Only the driver has the
> authority to make that claim. The passenger doesn't get to participate. The
> cop doesn't get to decide what credential you present. The specific act of
> presentation is semantically meaningful and must not be lost in the
> translation to digital interactions. This is the whole point of the
> Verifiable Presentation, to give the holder a chance to sign a statement
> with the same DID as the subject of the VC, and not only cryptographically
> verify they control the same crypto as the subject, but make a recordable
> attestation that they are that Subject.
>
> Your question of how does a recipient have any assurance that the
> application has integrity is the same as it ever was: source multiple
> verification mechanisms with intersupporting claims, much as RealID
> requires when onboarding for a RealID driver's license. If you trust the
> DMV to say that Joseph Andrieu is licensed and you have a PDF application
> for Joseph Andrieu and a VC from the DMV that says Joseph Andrieu is
> licensed to drive--and you have a verifiable presentation signed by the
> same DID that VC is issued to--then you can reasonably interpret that PDF
> as associated with that VC, although this structure is open to name
> collisions (rare with my name but less so with others). Better yet, put the
> DID that is the subject of the claim, in the PDF, then you have an
> assertion by the PDF issuer that this PDF is related to the same subject as
> the VC. My expectation is that despite the former hype about AgeOver
> credentials as single factor ZKPs, the truth is many VCs will need to embed
> human-testable correlations like a picture or physical descriptors (height,
> weight, etc.) so that the bouncer has some way to convince themselves we
> aren't dealing with a credential that was stolen along with access to
> private keys (which many *will* keep on their phone creating just that kind
> of attack).
>
> You still have to decide if you trust that PDF signer to make those
> attestations, but that problem is inevitable. You can't trust a signature
> without some concept of who the signer is and why you would trust them for
> that attestation.
>
>
>
> > The validity of the proof of insurance binding is dependent on the
> authority of the party binding the statement to the VC (presumably the
> insurer).
>
> >
>
> Ah – the issuer of the proof of insurance binding is **not** the issuer
> of the VC!   That’s part of the conundrum here – I have someone issuing a
> VC (the DMV issuing the drivers license) and someone else (the holder in VC
> terms) making a claim about that VC (the person submitting the proof of
> insurance).  But there is nothing directly connecting those two (though in
> this specific case you could attempt to see if the subject of the VC
> matches the issues of the proof – but that’s not a general case).
>
>
> That's right. The DMV is likely a consumer of the insurance statement, not
> its issuer. Only the signer of the PDF, the insurer, is authoritative for
> that signature.
>
> In short, your signed PDF is a signed credential just like a VC or VP. In
> order to validate it, you MUST trust the signer to have signed it properly
> and to have assessed the situation accurately enough to make the assertion.
> If you don't know the signer, you shouldn't trust it. If you do, you are
> open to exactly the kind of attack you're talking about. Don't trust
> signatures by unknown signers. In the VC subject=holder case, the VP signer
> is "known" because the DID in the VC is known.
>
> > If Joe Random hacker creates a PDF with my driver's license, then
> whoever is evaluating that binding should check to see if the signer of
> that PDF is in fact the same party as the subject of that driver's license.
>
> >
>
> Exactly as I noted above – but that is and will almost never be the case
> in our scenario.
>
>
> So what is your scenario?
>
> I think you want to detect that a bad actor isn't publishing false
> insurance statements. Is that right?
>
> Then maintain a list of qualified insurance providers and the
> cryptographic identifiers they use to sign things. DIDs and VCs don't avoid
> the need for an allow-list on those parties you trust for particular types
> of claims. There are ways to do this w/o an allow-list, but let's save that
> for another day.
>
>  > The only thing missing in this is an explicit statement by the signer
> as to the relationship between the VC and the PDF. If you had a Verifiable
> Presentation, I would put such a statement either directly in the VP or in
> a second VC. This latter option means you get a double the proof, but the
> first is a bit less standard in that you'd be using arbitrary properties in
> the VP which has its own consequences.
>
> >
>
> I thought about using a VP in this instance, but it would require creating
> a VC for the asset and who would sign that for proof? Wouldn’t it be the
> same subject/identity that is signer the tamper proofing – in which case,
> AFAICT, it doesn’t offer anything.
>
>
> The canonical pattern for subject=holder is
> 1. The Issuer requests a DID from the Subject, with a challenge string
> 2. The Holder presents a signed VP with the challenge string, using a DID
> 3. The Issuer verifies the signature on the VIP proving the requestor
> controls that DID (challenge string prevents replay attacks)
> 4. The Issuer issues a VC to the DID and delivers it to the requestor, who
> is now the holder of the VC (and its Subject)
>
> later...
>
> 5. A verifier asks for a VC, with a challenge string
> 6. The holder selects a VC
> 6. The holder signs a VP, with that VC and the challenge string, using the
> same DID that is the subject of the VC
> 7. The verifier verifies challenge string, the VP signature, the VC
> signature, and the equivalence of the DID Subject and VP signature
>
> The VP is proving that the Subject of the holder is now presenting it to
> the Verifier.
> Only the controller of the DID in question is able to go through all that.
>
> Of course, if the crypto secrets are compromised, none of this matters,
> but I think we all know the root vulnerability here. If we can't trust the
> key mgmt, all bets are off.
>
> So, if you're VC is stolen, yes, someone else could put that into another
> VP, but the signing identifier of that VP would not match the id of the
> subject of the VC, and, as such, it should fail validation (and depending
> on your definition, it would fail verification as well).
>
> If you treat the signed PDF conceptually *as* a VP, you can make the same
> guarantees.
>
> I think the conundrum you're stuck in is that you're thinking the signer
> of the PDF has no cryptographic relation to the subject of the VC. In that
> case, all of your comments sound correct. I don't think you can get the
> guarantees you want without that cryptographic linkage.
>
> Can you update your approach to include that cryptographic link?
>
> -j
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>