Service discovery from Controlled Identifier Documents (CIDs)

[Laurin-W]

I am designing a capability system based on VCs. When invoking a capability (creating a presentation) targeted at an endpoint of a specific controller, I need to obtain a challenge.
Could the spec define a VC API service in the controller's CID to discover the challenge endpoint of that controller?
This will require the VC API service(s) to define a service type name.

Perhaps related to #433.

[msporny]

The group discussed this on the 2025-03-11 telecon:

@dlongley noted that discovery of a challenge endpoint seems to indicate that you are an issuer that wants to make a call to a challenge endpoint, but don't know why you would have access to an endpoint to create a challenge which results in storage of information on a service, which would be a DoS vector. So, problematic from a security standpoint. Why would you need to discover where an endpoint is when you have been given authorization to use the endpoint. You wouldn't be doing discovery if you are authorized to use it (you either a priori know where to use the authz grant, or you have an authz where you don't know where to use it). @msporny noted that maybe their capability doesn't have a denotation mechanism (and was confused by it). @dlongley noted that maybe you get challenge from somewhere else (but need permission to get it from somewhere else to begin with or you can DoS their system).

It sounds like the use case has security issues and so the group needs to understand the use case in more detail. A flow of steps would help us understand what we can do to help here. @Laurin-W can you please provide a flow diagram or a series of detailed steps so we can analyze your capability system more effectively?

[Laurin-W]

Hi @msporny, thanks for you reply.

My use case was an invite link feature:

1. Alice creates an invite VC. The VC authorizes (among others) to read Alice's profile and photo for anonymous credentialSubjects. issuer is Alice's CID.
2. Alice sends Bob an invite link containing the VC, e.g. via a messenger (Alice does not know Bob's CID).
3. Bob fetches the issuer's (Alice's) CID which contains the VC endpoint URI.
4. Bob obtains a challenge from Alice's VC endpoint.
5. Bob creates a VP with the challenge, to fetch Alice's profile data (containing name and photo).
6. Bob fetches Alice's profile data with the VP.

n° Alice       Alice's data server       Alice's VC endpoint     Alice's CID                Bob                     Bob's VC endpoint
     |                 |                         |                    |                      |                            |
1    |>>>>>>>>>>>>>issue invite VC request>>>>>>>|                    |                      |                            |
     |<<<<<<<<<<<<<VC response<<<<<<<<<<<<<<<<<<<|                    |                      |                            |
     |                 |                         |                    |                      |                            |
2    |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Invite link with VC via messenger>>>>>>>>>>>>>>>>|                            |
     |                 |                         |                    |                      |                            |
3    |                 |                         |                    |<<GET<<<<<<<<<<<<<<<<<|                            |
     |                 |                         |                    |>>CID w/ VC endpoint>>|                            |
     |                 |                         |                    |                      |                            |
4    |                 |                         |<<<<<<<<<<<<<<obtain challenge<<<<<<<<<<<<<|                            |
     |                 |                         |>>>>>>>>>>>>>>challenge>>>>>>>>>>>>>>>>>>>>|                            |
     |                 |                         |                    |                      |                            |
5    |                 |                         |                    |                      |>>create VP for invite VC>>>|
     |                 |                         |                    |                      |<<signed VP>>>>>>>>>>>>>>>>>|
     |                 |                         |                    |                      |                            |
6    |                 |<<<<<<<<<<<<<<<<<<<<GET profile with VP<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<|                            |
     |                 |>>>>>>>>verify VP>>>>>>>>|                    |                      |                            |
     |                 |<<<<<<<<OK<<<<<<<<<<<<<<<|                    |                      |                            |        
     |                 |>>>>>>>>>>>>>>>>>>>>profile data>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|                            |
     |                 |                         |                    |                      |                            |

Instead of performing step 3, the VC endpoint information could be added to the VC. In either case, it would help to have RDF terminology to describe this.

Best,
Laurin

[msporny]

Instead of performing step 3, the VC endpoint information could be added to the VC.

If you want to use the VC API to do this, just set up an exchange for Bob, where Bob needs to present some proof of control over a private key in their DID/CID Document and then they get Alice's profile VC in return. It should be a pretty general version of this:

https://w3c-ccg.github.io/vc-api/#exchange-examples

... where Alice is the "Issuer Coordinator" and as a set up process (this is your step 1):

1. Creates a workflow for people to get their profile VC.
2. Creates an exchange specific for Bob, so that only Bob can retrieve the profile VC.

Then, Alice sets up a communication channel with Bob (your step 2) over Alice/Bob's protocol of choice -- could be email, Signal, anything, really -- could even be public since Bob has to cryptographically authenticate to use the endpoint.

You don't need step 3 since the exchange link /is/ the invite link.

Then Bob does steps 4-6 in your flow, but using https://w3c-ccg.github.io/vc-api/#exchange-examples

Bob is the "Holder" and Alice is the "Issuer Coordinator".

I don't think you need to use services to achieve your use case (it's simpler not to use services), it can just be plain VC API. Does that make sense?

[Laurin-W]

I see, thanks for spelling this out!

The use of workflows wasn't quite clear to me previously but it makes sense now.
(I had come up with my workflow before discovering the existence of this spec, it's not linked in the VC Overview or VC Extensions).

[msporny]

(I had come up with my workflow before discovering the existence of this spec, it's not linked in the VC Overview or VC Extensions).

Yes, and that's only because the VC API isn't global standards track yet; it's still being incubated. Once it's global standards track, we can include it in VC Overview.