Skip to content

Replace "challenge" and "domain" with the credential "expiry date" #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jceb opened this issue Dec 15, 2023 · 10 comments
Closed

Replace "challenge" and "domain" with the credential "expiry date" #20

jceb opened this issue Dec 15, 2023 · 10 comments

Comments

@jceb
Copy link
Contributor

jceb commented Dec 15, 2023

In the spec call on 2023-12-14 it was pointed out that the proposed security mechanism #3 that relies on the challenge and domain properties in a proof was created with an interactive exchange of credentials in mind. Furthermore, it doesn't work with JWTs #15. Therefore, a better mechanism should be researched.

@jceb jceb changed the title Find a better way of how to secure the currentness of the presentation Find a better way of how to secure the timeliness of the presentation Dec 15, 2023
@jceb
Copy link
Contributor Author

jceb commented Dec 15, 2023

@brianorwhatever thank you for pointing me in the direction of DIDComm's endpoint configuration: https://w3c.github.io/did-spec-registries/#didcommmessaging
It looks like they didn't publish a JSON-LD Context that makes it work. It would be great to have this feature to keep the nonce or hash in a separate property that can be extracted easily by the verifier, instead of having it as part of the URL. This would also enable us to support URLs that already include the challenge and domain search parameters.

@jceb
Copy link
Contributor Author

jceb commented Dec 20, 2023

For LD-proofs the nonce property (https://www.w3.org/TR/vc-data-integrity/#proofs) could also be used. I was first irritated by the description:

nonce: An OPTIONAL string value supplied by the proof creator. One use of this field is to increase privacy by decreasing linkability that is the result of deterministically generated signatures.

However, increased privacy is just "One use of this field". So I find it more fitting to use nonce than the challenge and domain properties that are meant for an interactive exchange of credentials.

@jceb
Copy link
Contributor Author

jceb commented Dec 20, 2023

For JWTs there's no field like nonce that could be used to ensure the timeliness of the referenced presentation. I'm leaning towards removing the whole timeliness check since it places an additional burden on implementers and it can't be support by both LD-proof and JWT secured presentations.

Implementers are still able to use the expiration date which appears to be good enough to me. @brianorwhatever what do you think?

@jceb jceb changed the title Find a better way of how to secure the timeliness of the presentation Replace "challenge" and "domain" with the credential "expiry date" Dec 21, 2023
@jceb
Copy link
Contributor Author

jceb commented Dec 21, 2023

Another mechanism for securing published VPs is to reference them via a did:webs URL, see https://trustoverip.github.io/tswg-did-method-webs-specification/index.html#signed-files. However, since the VP could be signed the did:webs mechanism seems to not provide much additional functionality. The use of did:webs URLs to VPs is already supported by the current version of this specification.

@OR13
Copy link

OR13 commented Dec 21, 2023

Data Integrity Proofs use new terms for old ideas... Domain is "Audience", Challenge is "Nonce".

Both are relevant to protocols where proof of possession is required.

@jceb
Copy link
Contributor Author

jceb commented Dec 22, 2023

Thanks, I'll the update the spec accordingly. The "proof of possession" doesn't apply to our case, it's more a "proof of timeliness" that can be achieved for public credentials.

@jceb jceb changed the title Replace "challenge" and "domain" with the credential "expiry date" Describe "proof of timeliness" via for JSON-LD an JWT credentials Dec 22, 2023
@jceb jceb changed the title Describe "proof of timeliness" via for JSON-LD an JWT credentials Describe "proof of timeliness" for JSON-LD an JWT credentials Dec 22, 2023
@brianorwhatever
Copy link
Contributor

@jceb the didcomm context is here https://didcomm.org/messaging/v2/index.json.

Proof of timeliness can be accomplished with DI using the expires property https://w3c.github.io/vc-data-integrity/#proofs and with jose using the exp claim.

We should not include a nonce/challenge/domain/audience as this would not gain any security benefits in a public presentation. The only use case I could see if I really squint would be to show that a public presentation is intended for a particular audience/domain but then why would it be a public presentation?

@jceb jceb changed the title Describe "proof of timeliness" for JSON-LD an JWT credentials Replace "challenge" and "domain" with the credential "expiry date" Jan 4, 2024
@jceb
Copy link
Contributor Author

jceb commented Jan 4, 2024

👍 good, let's remove the nonce/challenge/domain/audience references.

@jceb
Copy link
Contributor Author

jceb commented Jan 4, 2024

At the upcoming call on the 11th, we can talk about it a bit more.

@jceb
Copy link
Contributor Author

jceb commented Jan 4, 2024

I removed the references in commit 080dc6d of PR #3.

@jceb jceb closed this as completed Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants