Add .well-known/did-configuration demo #2
Conversation
| "name": "demo", | ||
| "version": "0.1.0", | ||
| "private": true, | ||
| "homepage": "https://well-known.transmute-did.com", |
There was a problem hiding this comment.
This can be changed to a DIF domain, I just added this for testing purposes.
| @@ -0,0 +1,7 @@ | |||
| { | |||
There was a problem hiding this comment.
This is the outer claims object, what I like about this format is that other claim formats can be added later. what I don't like about JWTs is that they are opaque until you decode them.
If this were a linked data signature the claim would be easier to read.
| @@ -0,0 +1 @@ | |||
| well-known.transmute-did.com | |||
There was a problem hiding this comment.
This can be changed to DIF if desired
| const path = require("path"); | ||
| const ES256K = require("@transmute/es256k-jws-ts"); | ||
|
|
||
| // feel free to impersonate me :/ |
There was a problem hiding this comment.
WebOfTrustInfo/btcr-hackathon-2019#6
I didn't have to link a leaked key, but I did.
this key is used all over the place in my ES256K tests, I will need to revoke this key at some point, and generate a clean set of claims for the demo.
| const innerPayload = { | ||
| iss: "did:btcr:xxcl-lzpq-q83a-0d5", | ||
| domain: "example.com", | ||
| exp: Math.floor(Date.now() / 1000) + 60 * 60 * defaultExpiresInHours |
There was a problem hiding this comment.
default expiration is 1 hour for this library, I like that a DID controller can control when their domain claim will expire independent of the domain admin.
| const domainClaimJwt = await ES256K.JWT.sign(innerPayload, privateJWK); | ||
|
|
||
| const outerPayload = { | ||
| // typ: "jwt", |
There was a problem hiding this comment.
if we want to keep the signed outer payload its here, otherwise this should be removed.
| const verified = await ES256K.JWT.verify(jwt, publicKey.publicKeyJwk); | ||
|
|
||
| if (verified.iss === did) { | ||
| console.log(did, " is authorized for: ", verified.domain); |
There was a problem hiding this comment.
what should happen here? probably the domain associating with the config should be matched against the claim.
If they do not match, the claim should throw...
| state = {}; | ||
|
|
||
| async componentWillMount() { | ||
| const authorizedDids = await getAuthorizedDids( |
There was a problem hiding this comment.
thanks to the CORs headers for universal resolver a single page app can lookup and verify its own authorized DIDs.
… into feat/add-well-known-did-configuration-demo
This PR does a small reorg and adds a demo for
.well-known/did-configuration.other static well-known uris can be added later.
The demo opens up more questions about what "verification" of claims mean.
For example, the verifier needs to match the domain that was signed with the request for the claim.
(currently not implemented).