Remove biometric templates from DID spec elements

[johncallahan]

Based on the "Truths about Biometrics" paper drafted at RWOT6, it was recommended that biometric data (partial or encrypted) should not be in a DID Document. Rather, only service endpoints (URLs and otherwise) to any biometric services (partial or encrypted) should be in a DID Document. Please remove all biometric template and use service endpoint examples (e.g., BOPS, etc.)

[msporny]

If we remove everything from the "authentication" field, then it will not be possible to authenticate using biometrics at all in the DID spec (which is not what you want, IIUC).

We need to put something in the authentication field. It doesn't have to be partial biometric information (although the previous examples didn't mean to include partial biometric data, but a system-specific template that held no biometric data).

Here's the fundamental thing we're trying to do: 1) specify that you can authenticate using a biometric mechanism, 2) specify that the entity represented by the DID wants to authenticate in this way, and 3) provide the necessary details that enables this sort of authentication to happen (where services are just one way we could do this).

What would help get this issue resolved is providing the sorts of data that a BOPS server needs to bootstrap the exchange. For example, where is the biometric image delivered, what is the specific biometric protocol, is there metadata that needs to go along w/ the request, etc.

[johncallahan]

I agree that something must be in the authentication field. It's the actual template (partial or full) that the report team determine is problematic. In the upcoming report, we propose that biometric auth could happen under the following cases:

(1) a public key value and type "ieee2410-2017" be specified to signal the user must biometrically authenticate using a BOPS client on the client device (similar to the RSA method that doesn't need a service endpoint IIUC). I will also assert that "fido-uaf" could also be a type similarly with a public key to a FIDO UAF client.

(2) a service endpoint (with type "ieee2410-2017") is specified (via URL) with a userid and public key requesting the endpoint perform biometric authentication via push notification to an enrolled account specified by the userid (or hash?). The IBV (initial biometric vector) is already stored and enrolled on the server endpoint (a BOPS server), so it just needs the userid and pub key of the enrolled user. This is covered in a few of the DID auth cases by Marcus. I assert the same could be tru of a FIDO UAF service.

In both cases, I'm not sure if the userid (endpoint specific) or a hash is appropriate, but the endpoint seems critical in #2 of course. The DID and DID document would be created on BOPS enrollment as per the Horcrux method. That's direct with a server. Any movement to an additional or replacement device would have to edit the DID (after DID auth of course) or orphan it. This happens already with BOPS on device loss or damage.

I remain concerned about BOPS biometric shares: are multiple keys listed with multiple service endpoints? Should we indicate 1 of 2 shares, 1 of 3 shares, 2 of 3 shares in the auth block to show this is a fragment of a group? Or is that in the BOPS service endpoint only? I am leaning to the latter initially, but recovery mechanisms might need the former. Probably expand on this later.

Finally, a BOPS server endpoint requires a client cert to reach its RESTful API. That's how the client apps work and trusted relying parties (who request SessionOpportunities in the protocol). Two-way TLS. It's in the standard to secure the conversation both ways. How would an RP with a DID handle this?

[johncallahan]

Here's an example of (2)

"@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "authentication": [{ "type": "ieee2410-2017", "userid": "0123456789", "publicKey": "did:example:123456789abcdefghi#keys-1" }], "service": [{ "type": "BOPSService", "serviceEndpoint": "https://bops.example.com/enterprise/" }]

[johncallahan]

An example of (1) might be

"@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "authentication": [{ "type": "ieee2410-2017", "publicKey": "did:example:123456789abcdefghi#keys-1" }]

With no service endpoint, the requestor (who submitted the DID) must biometrically authenticate with a BOPS client. I'm leaving out some other parameters of the BOPS envelope (and that we use ECC not RSA), but I think you get the gist.

[johncallahan]

Instead of userid, let's use the DID itself instead. Consider:

"@context": "https://w3id.org/did/v1", "id": "did:example:123456789abcdefghi", "publicKey": [{ "id": "did:example:123456789abcdefghi#keys-1", "type": "RsaVerificationKey2018", "owner": "did:example:123456789abcdefghi", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" }], "authentication": [{ "type": "ieee2410-2017", "publicKey": "did:example:123456789abcdefghi#keys-1" }], "service": [{ "type": "BOPSService", "serviceEndpoint": "https://bops.example.com/enterprise/did:example:123456789abcdefghi" }]

This allows the BOPS server to contact the DID subject via a trusted channel (e.g., push notification) to authenticate biometrically (e.g., on their mobile device) in agreement with the DID auth use cases.

[msporny]

@johncallahan ... finally got around to fixing this in the spec. Thank you. Please review PR #76 and make sure I made the change you were suggesting.