Define or forbid human readable exchange-id

[OR13]

consider:

POST /exchanges/credential-refresh
POST /exchanges/definition-oil-import-from-ca
POST /exchanges/definition-steel-import-from-mx

vs

POST /exchanges/urn:uuid:123

is guessable names a security issue?

if we support a single human readable name, does that mean we support all the other ones?

where is the registry for human readable "workflow definition names" maintained.

[mprorock]

if you have a GET for /exchanges and are authorized i would assume you get a list of supported workflows, names, descriptions based on auth - I am working on a PR for this on VC-API

[OR13]

Is there a better issue or PR to track this against?

[mprorock]

related most strongly to this

[OR13]

Seems blocked by VC-API change set negotiations.

[nissimsan]

Unassigning myself, as we just decided to wait with this.

[OR13]

I don't intend to support the proposed API changes.

[BenjaminMoe]

My impression is that we have /presentations/available and /presentation/submissions which needs to be defined on the end of a URL which gives you flexibility on what you prepend onto the path.

I propose that this flexibility is already allowed in this spec, and that these breaking changes should not be applied.

/credential-refresh/presentations/available
/definition-oil-import-from-ca/presentations/available
/definition-steel-import-from-mx/presentations/available

[nissimsan]

Someone else but Transmute needs to comment on this, pls. We are not planning on impl these APIs.

[brownoxford]

ping @mprorock

[mkhraisha]

VC API defines an exchanges API, our goal on the traceability interop API is to be a superset of the VC-API, and as such we should support /exchanges.

[nissimsan]

Should this be IRIs instead of UUIDs?

IRIs are still unique. But would allow us to point to workflow definitions. For example:

  "workflow": {
    "definition": [
      "https://w3c-ccg.github.io/traceability-vocab/#mill-test-certification"
    ]
  },

[OR13]

we don't need to change anything to make them IRIs... they are already supposed to be IRIs given we are using JSON-LD.

we might need to relax "MUST" statements in the profile that speak to UUIDs

@nissimsan this comment is also a bit confusing on this issue, since this issue is about changes the vc-api has been making to:

presentations/available and presentations/submissions.

... AFAIK those new endpoints have no tests.

[nissimsan]

@OR13,

we might need to relax "MUST" statements in the profile that speak to UUIDs.

Yes, if I remember the conversation correctly this was the essential part.

[BenjaminMoe]

Proposal for resolution:

• We allow for human readable paths for exchange end points
• We DO NOT allow for human readable paths for exchange end points

1. We agree on this definition
2. We have updated the spec to reflect this.

[nissimsan]

As far as I can tell nowhere in the spec do we actually have this "MUST" suggested in this issue. So I agree we can just go ahead and close this ticket.

[nissimsan]

@OR13, are you okay to close this?

[OR13]

I'm good to close this, not planning to implement at this time.