Skip to content
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

Replace RsaSignature2017 by a standard JWA signature #9

Closed
brentzundel opened this issue Sep 20, 2019 · 8 comments
Closed

Replace RsaSignature2017 by a standard JWA signature #9

brentzundel opened this issue Sep 20, 2019 · 8 comments
Assignees
Labels
pending close Issue will be closed shortly if no objections

Comments

@brentzundel
Copy link
Member

@AxelNennker moved from CCG (w3c-ccg/did-spec#39)

@brentzundel brentzundel transferred this issue from w3c/did-use-cases Sep 20, 2019
@msporny msporny added the discuss Needs further discussion before a pull request can be created label Oct 1, 2019
@selfissued
Copy link
Contributor

I agree that we should replace RSASignature2017 with use of the JWS and JWA standards. This will increase interop and reduce the footprint of new standards we need to create to finish the DID spec and things that it relies upon.

@msporny
Copy link
Member

msporny commented Feb 7, 2020

The specification should clearly state that proof mechanisms are outside of the scope of the specification. I'd argue that the specification should probably remove the proof property as well. If people want to use JSON-LD + Linked Data Security mechanisms they can do that... if folks want to use JWS, they can do that too, but protecting DID Documents using either mechanisms shouldn't be mandated or prevented by the spec.

@jricher
Copy link
Contributor

jricher commented Feb 25, 2020

I think that specifying the proofing mechanism is outside the scope of this spec, but the data model itself needs to have a notional place for the proof and define aspects of that proof. I would go so far as to say that we also need to have a set of requirements that proofing mechanisms fulfill, in addition to a way to signal the mechanism in use on a document. The details are the trick here, for instance requiring that the signature method is itself covered by the signature.

@msporny msporny added ready for pr Issue is ready for a PR and removed discuss Needs further discussion before a pull request can be created labels Feb 25, 2020
@msporny
Copy link
Member

msporny commented Feb 25, 2020

I'll try to write a PR for this.

@OR13
Copy link
Contributor

OR13 commented Mar 15, 2020

This issue is stale... there are no references to "RsaSignature2017" in the current spec... There is a reference to proof https://w3c.github.io/did-core/#proof

I don't think this issue is ready for a PR... I created a new ticket for:

Define "proof" property of did document. #223

@jricher @selfissued @msporny If there is consensus on this approach, please close this issue and add any comments to the one linked above.

@msporny
Copy link
Member

msporny commented May 12, 2020

RsaVerificationKey2018 still exists in the spec - I expect @selfissued will have a concern with that... and we may change to Ed25519VerificationKey2020 for examples, which I expect @selfissued may still have a concern with, even with publicKeyJwk examples in the spec.

@rhiaro rhiaro added pr exists There is an open PR to address this issue and removed ready for pr Issue is ready for a PR labels Jun 1, 2020
@msporny
Copy link
Member

msporny commented Jun 16, 2020

The RSA Verification Key examples have been changed to Ed25519 ones. There is a different issue opened for updating the JWK examples, see #171.

That means that this issue can be closed now.

@msporny msporny added pending close Issue will be closed shortly if no objections and removed pr exists There is an open PR to address this issue labels Jun 16, 2020
@brentzundel
Copy link
Member Author

No comments since marked pending close, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending close Issue will be closed shortly if no objections
Projects
None yet
Development

No branches or pull requests

6 participants