Ecosystem Guidance (basic section without the examples) #300
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jogu
reviewed
Oct 7, 2025
Sakurann
reviewed
Oct 7, 2025
Sakurann
reviewed
Oct 7, 2025
Sakurann
reviewed
Oct 7, 2025
| - Credential Offer invocation mechanisms. | ||
| - Key attestation formats. | ||
| - X509 Verifier Authentication certificate profiles. | ||
| - Presentation mechanisms. |
Contributor
There was a problem hiding this comment.
what does this mean? DC API?
Suggested change
| - Presentation mechanisms. | |
| - Whether to use DC API or not |
Contributor
Author
There was a problem hiding this comment.
It is all three of: DC API, Redirects with custom schemes or Redirects with 'claim' URLs
Contributor
Author
There was a problem hiding this comment.
update to be more explicit, inline with the other changes
Sakurann
reviewed
Oct 7, 2025
applying suggestions Co-authored-by: Kristina <[email protected]> Co-authored-by: Joseph Heenan <[email protected]>
jogu
approved these changes
Oct 7, 2025
Sakurann
approved these changes
Oct 7, 2025
Sakurann
reviewed
Oct 7, 2025
jogu
reviewed
Oct 9, 2025
jogu
reviewed
Oct 9, 2025
|
|
||
| This document intentionally leaves certain extensions for ecosystems to define, in order to enable broad compatibility across differing or even conflicting requirements. These include: | ||
|
|
||
| - Which Credential format to support across issuance and presentation. |
Contributor
There was a problem hiding this comment.
Discussed on APAC WG call this morning; concerns about this mixing presentation & issuance together; probably need to make clear this is a choice as well?
Suggested change
| - Which Credential format to support across issuance and presentation. | |
| - Whether to adopt the Presentation profile, Issuance profile, or both | |
| - Which Credential format to support across issuance and presentation. |
jogu
reviewed
Oct 9, 2025
|
|
||
| ### Improved Baseline Interoperability | ||
|
|
||
| This ecosystem prioritizes interoperability among all Wallets and Issuers, without requiring any pre-existing relationships, and supports both ISO mdocs and SD-JWT VCs. To achieve this, the ecosystem could define the following: |
Contributor
There was a problem hiding this comment.
Query from this morning's APAC call - should we split these up into presentation/issuance examples?
Contributor
There was a problem hiding this comment.
confirmed in the EU call to split
jogu
reviewed
Oct 9, 2025
|
|
||
| This ecosystem prioritizes interoperability among all Wallets and Issuers, without requiring any pre-existing relationships, and supports both ISO mdocs and SD-JWT VCs. To achieve this, the ecosystem could define the following: | ||
|
|
||
| - Wallets MUST support both mdoc and sd-jwt-vc. Issuers MAY issue in either format. |
Contributor
There was a problem hiding this comment.
Discussion from this morning's APAC call - not 100% sure about the use of a MUST here:
- This isn't a normative MUST in the actual HAIP spec
- If you're reading too quickly you might read this as HAIP actually requiring mdoc & sd-jwt to be supported always
Contributor
There was a problem hiding this comment.
EU call discussion:
- agreed it might be confusing.
- use a box or something to make it very clear that this part of the spec is different from the rest of the spec
Co-authored-by: Joseph Heenan <[email protected]>
Sakurann
reviewed
Oct 9, 2025
|
|
||
| Below are two non-normative examples illustrating how an ecosystem may define the above elements to achieve its specific goals and preferences. | ||
|
|
||
| ### Improved Baseline Interoperability |
Contributor
There was a problem hiding this comment.
Suggested change
| ### Improved Baseline Interoperability | |
| ### Example Ecosystem: Improved Baseline Interoperability |
Sakurann
reviewed
Oct 9, 2025
|
|
||
| Making these choices maximizes interoperability between the parties in the ecosystem while minimizing the burden on Issuers and Verifiers. This comes at the expense of an increased burden on Wallets as well as the potential privacy and security issues in (#interop-key-attestations). | ||
|
|
||
| ### Existing Curve Requirements |
Contributor
There was a problem hiding this comment.
Suggested change
| ### Existing Curve Requirements | |
| ### Example: Existing Curve Requirements |
Sakurann
reviewed
Oct 9, 2025
Sakurann
changed the title
paulbastian
approved these changes
Oct 9, 2025
tlodderstedt
approved these changes
Oct 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #265
This lists the extension points across the protocol and provides two examples of further extensions (one roughly matching EU and the other mDL).
There are several extension points that aren't mentioned, as this covers the main ones.