Skip to content

Conversation

@Sakurann
Copy link
Collaborator

@Sakurann Sakurann commented Apr 2, 2025

resolves #397

  • adds a processing rule that When the same Credential fulfills more than one Credential Query in a request, that Credential MUST contain the combination of claims requested by those Credential Queries. However, that Credential MUST NOT contain claims not requested by either of the Credential Queries.
    • I added it in a place that in my opinion made it most clear that this transcends claims and credential selection, but it can also be moved to after line 966

editorial changes

  • consolidated security considerations section in one place (already using client identifier prefix term)
  • some whitespace nits

.DS_Store Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't commit this file

Copy link
Member

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides the comment from @charsleysa, this looks good to me, and feels like a simple approach.


#### Selecting Claims {#selecting_claims}
When the same Credential fulfills more than one Credential Query in a request, that Credential MUST contain
the combination of claims requested by those Credential Queries. However, that Credential MUST NOT contain
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this disallow the simple option to make two distinct presentations for the same credential?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the question would be 'what defines a credential'? Would it be more accurate to talk about this in terms of presentations, rather than credentials:

I.e.

'When the same Credential Presentation fulfills more than one Credential Query in a request, that Credential Presentation MUST contain the combination of claims requested by those Credential Queries. However, that Credential Presentation MUST NOT contain claims not requested by any of the Credential Queries that it fulfills."

That would allow the wallet to make two distinct or a single one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, Paul. I was not sure if we wanted to allow "the simple option to make two distinct presentations for the same credential". if we do, Verifier would need to support both cases, which might be harder?

Copy link
Contributor

@paulbastian paulbastian Apr 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but I don't see why we should make wallet implementations harder either. Most verifier implementations may not even check if more data than necessary was delivered

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's actually more work for the verifier:

AIUI it is always valid in these cases to answer the different credential queries with different credentials (I don't believe we even have a way to express that two different credential queries must be the same credential, there are arguably use-cases but they are pretty thin).

As a consequence, verifiers must be able to support different credentials presented for the different credential queries (at least to be correct). If they support that, then they will naturally support @paulbastian's desired mechanism (as it is likely indistinguishable from a verifiers perspective). So being permissive for wallets lowers their burden at no interop cost, so seems like win.

(Verifier processing logic is really just: for each queryId verify credential, extract relevant claims from credential to internal format. All this text changes is to prevent Verifiers being overly strict (ones who want to be now have to do some extra work to de-dupe credentials before running their check for unexpected claims, but for those who don't it is no more work.))

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a consequence, verifiers must be able to support different credentials presented for the different credential queries (at least to be correct). If they support that, then they will naturally support @paulbastian's desired mechanism

that is a fair point.

I'll commit my suggestion below that I believe fulfills @paulbastian's original point?

editorial. accepting as an editor of the spec and since it's a PR on a PR i did
.DS_Store Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should be removed from the PR

Comment on lines 918 to 920
When the same Credential fulfills more than one Credential Query in a request, that Credential MAY contain
the combination of claims requested by those Credential Queries. However, in this case, the Credential MUST NOT contain
claims not requested by any of the Credential Queries.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should go below "selecting claims".

@danielfett
Copy link
Contributor

This changes a lot of unrelated things, so should probably be rebased and checked again.

@Sakurann
Copy link
Collaborator Author

Sakurann commented Apr 7, 2025

WG discussion.
@Sakurann and @danielfett to take this offline to bikeshed the text. wg agrees on what we are trying to say

@Sakurann Sakurann added editors and removed discuss labels Apr 7, 2025
Co-authored-by: Daniel Fett <mail@danielfett.de>
Copy link
Contributor

@charsleysa charsleysa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as long as the .DS_Store file is removed

@Sakurann Sakurann merged commit 1a54050 into main Apr 11, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

same credential fulfilling multiple credential queries

10 participants