Repository navigation
profile Trust Marks for wallet authorization instead of restating Federation - #71
peppelinux wants to merge 15 commits into
Conversation
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
samuelmr
left a comment
samuelmr
left a comment
There was a problem hiding this comment.
Please consider the feedback in the comments
| Profiles MAY convey `dcql_queries`-related constraints using Trust Marks bound | ||
| to a Credential Verifier, in addition to or instead of `metadata` and | ||
| `metadata_policy`, when the Trust Framework defines how those marks are | ||
| interpreted. |
There was a problem hiding this comment.
This may seem like a simple statement, but I'm worried about the implementation details. If the client resolving the trust needs to search for dcql_queries in subordinate statements and trust marks, the specification should clearly define the expected behaviour when a trust mark and a subordinate statement conflict.
In my opinion, we should leave the constraints-in-trust-marks feature out for now.
There was a problem hiding this comment.
@peppelinux, hat's the syntax for conveying these constraints? I don't think the PR says. What's an example, maybe?
There was a problem hiding this comment.
I'm not sure I really understand what the purpose of conveying DCQL-related constraints in trust marks is. An example, and an explanation of the interaction between multiple constraints in particular, would be helpful.
| When a Trust Framework requires a Trust Mark for a transaction, the Entity | ||
| evaluating trust MUST verify that Trust Mark as specified in | ||
| [@!OpenID.Federation], including signature validation and status checks, and | ||
| MUST NOT complete that transaction if a required Trust Mark is missing, expired, |
There was a problem hiding this comment.
MUST NOT is a strong requirement.
Compared with how eIDAS wallet-relying party registration certificates work, they should present a warning that the user can override.
One may argue that that's not strictly "When a Trust Framework requires a Trust Mark for a transaction", but the current wording leads to ambiguity in cases where Trust Marks are defined and used in a Trust Framework, and the verifier is required to present their trust marks, but a trust mark is not strictly "required for a transaction".
There was a problem hiding this comment.
What do you mean by "the verifier is required to present their trust marks", @samuelmr? Are you talking about a requirement to display them to the end-user somehow?
There was a problem hiding this comment.
I'm thinking about a Trust Framework that would state something like the following in its rulebook: "If the verifier of digital credentials holds an 'Ethical Data User' trust mark, the verifier shall advertise that trust mark in its entity configuration so that a wallet can verify it and display it to the wallet user."
The main point is that trust evaluation is not always fully automated. Sometimes, it's an evaluation that a person makes based on the information available. The Wallet Architectures spec should also cater for the latter cases.
There was a problem hiding this comment.
Agree the overridable cases are real e.g. eudi. My concern is the proposed fix. Replacing MUST NOT complete with the "trust framework decides" pushes the abort-vs-warn signal out of the protocol into a human-readable language and loses the deterministic machine-readable behaviour that will be needed for unattended/agentic flows. There should be an option to express it in a deterministic, machine-readable way that it is critical.
I also see a granularity issue, i.e. we can take into account that there may be a couple of trust marks associated with the verifier with different queries inside to indicate different behaviour for the presentation of more and less sensitive credentials and how to manage potential conflicts and overlaps.
There was a problem hiding this comment.
I agree that unfortunately we will need to replace the MUST NOT with some optionality since ecosystems have already decided they want to allow that. I agree with @lj-raidiam that the optionality should be machine-parseable; not only for unattended flows, but also to make the UX easier to implement without a lot of ecosystem-specific code.
removed unused trust-model taxonomy from Terminology
Co-authored-by: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com>
Co-authored-by: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com>
chore: clarify that Wallet Instance types do not change federation processing
expand example 1 openid_credential_verifier metadata
GitHub Actions
Failure
|
I read all the comments and I agreed with them all, the result I propose is brought in this commit 0436641 |
|
@fmarino-ipzs I'd ask your review before the final approval |
fkj
left a comment
fkj
left a comment
There was a problem hiding this comment.
Generally looks fine to me, but one nit.
| "format": "dc+sd-jwt", | ||
| "meta": { | ||
| "vct_values": [ | ||
| "urn:eudi:pid:1" |
There was a problem hiding this comment.
Should perhaps use a more example-like value instead of something that "looks" like an EUDI PID?
This branch was successfully deployed
5 participants
This PR resolves #66 by profiling Trust Marks for wallet ecosystems rather than dropping section 7.4 or repeating OpenID Federation.
Typical uses are about Credential Issuer entitlement, Credential Verifier authorization, Wallet Provider assurance.
If a Trust Framework requires a Trust Mark, it MUST be verified and MUST block the transaction when missing, expired, or revoked.