Feature Discovery <> Profiles

[bumblefudge]

Discussed on today's call: would a restricted or "secure" profile that subsetted features of v2.1 be able to be signaled by wallets and/or verifiers via OIDC (or next-gen OIDC) metadata? And/or in credential manifests?

It's worth exploring the feasibility of a feature-restricted profile being declarable in v3 (if OIDC4VP implementers design a profile of v2.1 and want interop with other implementations without the risk of bad UX due to, e.g., JSONSchema security or constrained credential-filtering in-wallet being part of that profile).

Next steps: adding a use-case to the use-cases section describing a "one-credential at a time, one claims format at a time" use-case, ideally adding details about trust-levels between actors or other drivers of constraints that the profile would optimize for?

[kimdhamilton]

Another approach, given that v3 can be breaking, is to flip this. This would make the base the "secure" version while pushing less secure functionality to features.

This has better design warm and fuzzies, but it may not be possible for reasons i am not yet thinking of

[csuwildcat]

Is there anything actionable here? It is marked as a blocker for 2.1, but I am not sure what is desired for this release.

[csuwildcat]

@bumblefudge @kimdhamilton @Sakurann can you all, and/or OIDC-active participants, define what you would like in a reduced profile, and how that might impact the spec? What are the changes desired for 2.0/2.1 that help accomplish this?