search

TBD54566975 / known-customer-credential

3 stars 1 forks source link

Add service discoverability #29 #30

Closed KendallWeihe closed 3 weeks ago

KendallWeihe commented 1 month ago

Closes #29

Mostly, I ripped the language from the tbdex spec.

@decentralgabe @frankhinek @mistermoe I've set the type to still be IDV but is this right? I'm not familiar with verifiable registries, but my surface understanding is this helps crawlers? I'm out of my depths here. I can remove the type row from the table if I'm off, and/or open a ticket for further discussion.

Relevant comment regarding the swimlane diagram.

frankhinek commented 1 month ago

We could potentially use the OID4VCI service type from the DID Spec Registries. I can't think of a reason why it wouldn't work given that it is expected that {OID4VCI_service_endpoint}/.well-known/openid-credential-issuer matches the expectation we've written in our KCC spec draft.

If we do have a reason to define a different service type, like IDV, then we should add it to the DID Spec Registry.

frankhinek commented 1 month ago

@decentralgabe I was hoping there might be some illuminating information from the eKYC & IDA Working Group but it appears that they are excluding DIDs from all of their work, which means there would be no guidance about eKYC/IDA discoverability in the context of DIDs.

KendallWeihe commented 3 weeks ago

We could potentially use the OID4VCI service type from the DID Spec Registries.

I propose we do this. I opened #36 in place of this PR. I propose we ✅ and merge #36 and close this PR.

KendallWeihe commented 3 weeks ago

Update: from #36

This isn't quite right because the point of initiation is SIOPv2, not OID4VCI. Closing this PR in favor of #30.

Moving forward with the proposal here