-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: Use did:peer:4 by default for DID Exchange #2166
Changes from 2 commits
0cd2ca1
fdb7086
3af94da
0e1e56d
b623c54
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,6 +31,8 @@ import { | |
tryParseDid, | ||
didKeyToInstanceOfKey, | ||
DidRepository, | ||
didKeyToVerkey, | ||
parseDid, | ||
} from '@credo-ts/core' | ||
|
||
import { Attachment, AttachmentData } from '../../decorators/attachment/Attachment' | ||
|
@@ -284,32 +286,33 @@ export class DidExchangeProtocol { | |
const didDocument = await createPeerDidFromServices(agentContext, services, numAlgo) | ||
const message = new DidExchangeResponseMessage({ did: didDocument.id, threadId }) | ||
|
||
// DID Rotate attachment should be signed with invitation keys | ||
const invitationRecipientKeys = outOfBandRecord.outOfBandInvitation | ||
.getInlineServices() | ||
.map((s) => s.recipientKeys) | ||
.reduce((acc, curr) => acc.concat(curr), []) | ||
|
||
// In case the DID Exchange started with an implicit invitation, take all recipient keys from the corresponding DID | ||
for (const did of outOfBandRecord.outOfBandInvitation.getDidServices()) { | ||
invitationRecipientKeys.push( | ||
...(await getDidDocumentForCreatedDid(agentContext, parseDid(did).did)).recipientKeys.map( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we always need to do this, or only for implicit? Because now we run this always? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the comment is misleading. It is useful for resolvable DIDs in general. However I'll review the DID Exchange Response creation more in details just to make sure it works properly in all cases. |
||
(key) => key.publicKeyBase58 | ||
) | ||
) | ||
} | ||
|
||
if (numAlgo === PeerDidNumAlgo.GenesisDoc) { | ||
message.didDoc = await this.createSignedAttachment( | ||
agentContext, | ||
didDocument.toJSON(), | ||
Array.from( | ||
new Set( | ||
services | ||
.map((s) => s.recipientKeys) | ||
.reduce((acc, curr) => acc.concat(curr), []) | ||
.map((key) => key.publicKeyBase58) | ||
) | ||
) | ||
Array.from(new Set(invitationRecipientKeys.map(didKeyToVerkey))) | ||
) | ||
} else { | ||
// We assume any other case is a resolvable did (e.g. did:peer:2 or did:peer:4) | ||
message.didRotate = await this.createSignedAttachment( | ||
agentContext, | ||
didDocument.id, | ||
Array.from( | ||
new Set( | ||
services | ||
.map((s) => s.recipientKeys) | ||
.reduce((acc, curr) => acc.concat(curr), []) | ||
.map((key) => key.publicKeyBase58) | ||
) | ||
) | ||
Array.from(new Set(invitationRecipientKeys.map(didKeyToVerkey))) | ||
) | ||
} | ||
|
||
|
@@ -462,6 +465,7 @@ export class DidExchangeProtocol { | |
data: string | Record<string, unknown>, | ||
verkeys: string[] | ||
) { | ||
this.logger.debug(`Creating signed attachment with keys ${JSON.stringify(verkeys)}`) | ||
const signedAttach = new Attachment({ | ||
mimeType: typeof data === 'string' ? undefined : 'application/json', | ||
data: new AttachmentData({ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -132,12 +132,14 @@ export function routingToServices(routing: Routing): ResolvedDidCommService[] { | |
} | ||
|
||
export async function getDidDocumentForCreatedDid(agentContext: AgentContext, did: string) { | ||
// Ensure that the DID has been created by us | ||
const didRecord = await agentContext.dependencyManager.resolve(DidRepository).findCreatedDid(agentContext, did) | ||
|
||
if (!didRecord?.didDocument) { | ||
throw new CredoError(`Could not get DidDocument for created did ${did}`) | ||
if (!didRecord) { | ||
throw new CredoError(`Could not find created did ${did}`) | ||
} | ||
return didRecord.didDocument | ||
|
||
const didsApi = agentContext.dependencyManager.resolve(DidsApi) | ||
return await didsApi.resolveDidDocument(did) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm 🤔 Are there cases where we don't store our own did? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not really, but I wanted to take all the advantages of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is okay! Just curious :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It also has the benefit of caching, and even DIDs created by us, but not managed by us (e.g. think a did web for which we have one key, but it's stored outside of credo as it's regularly updated) |
||
} | ||
|
||
/** | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is different right? InvitationDid is usually not the final did
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case it should be the same, since we are not setting it as an multiUse invitation. I did this trick because
OutOfBandInvitation.invitationdDids
is dynamically generating peer:2 DIDs and this does not work directly when querying peer:4 DIDs.But I'll take a second look to it to see if everything is in place.