biscuit-auth / biscuit

delegated, decentralized, capabilities based authorization token
Apache License 2.0
914 stars 26 forks source link

DID / DPKI integration #105

Open BastienVigneron opened 2 years ago

BastienVigneron commented 2 years ago

Hello Biscuit team,

One of the first sentence of your documentation say :

One of those building blocks is an authorization token that is signed with public key cryptography (like JWT), so that any service knowing the public key can verify the token.

This implies to distribute public keys on all services that have to verify tokens, manage key renewal. Revocation, ...

Is it in your plans to include DID based signature or encapsulate the biscuit in a verifiable token ?

This cloud solve traditional PKI problems by using a DPKI based identity / signature management.

tarcieri commented 2 years ago

One of the interesting things to keep in mind about Biscuits (and Macaroons, and SPKI/SDSI) is they can lean on their built-in support for delegation to express various PKI patterns.

Especially with support for third party blocks/caveats (#103) this can solve problems analogous to certificate authorities and certificate chains.

(In fact it can go far beyond that... you can express SAML/OIDC-like relationships but maintaining cryptographic bindings across principals, which effectively eliminates audience confusion attacks via cryptography)

As such, Biscuits don't really gain much from integrations with other PKI systems, especially because the integration patterns are subtly different (more like OCap patterns)

Geal commented 2 years ago

DIDs and VCs are not in the roadmap right now, although we've been looking at them, and generally we're interested in how Biscuit can integrate with other systems. And as @tarcieri said, with the third party blocks feature coming up, there will be a lot of cool patterns to explore

BastienVigneron commented 2 years ago

Thank you Tony and Geoffroy. I have to investigate on third party blocks but I'm not sure its allow easily to integrate with DID.

I guess what we need is only the DID of the user (controller in DID world) and the DID of the Biscuit emitter, and of course appropriate signatures of both.

For information I'm trying to evaluate the relevance of the integration of Biscuit in this context.

Voronar commented 5 months ago

I'm also interested in DID usage in a form of a root signature key (of different cryptographic algorithms) for Biscuit issuer, but as I know Biscuit doesn't allow any cryptographic algorithms other than Ed25519 for the root key. The only OCap-like authorization protocol with built in DID support that comes in mind is UCAN.

Geal commented 5 months ago

Support for more algorithms is planned, and we have some tests in https://github.com/biscuit-auth/biscuit-rust/pull/108 Right now the goal is making sure that other libraries can implement it in the same way before adding that to the specification