search

w3c / vc-data-integrity

W3C Data Integrity Specification
https://w3c.github.io/vc-data-integrity/
Other
42 stars 19 forks source link

Domain and range of sec:publicKey #74

Closed csarven closed 1 year ago

csarven commented 1 year ago

(Not sure if this issue should be moved to https://github.com/w3c-ccg/security-vocab/ but filing it here for now.)

https://github.com/w3c/vc-data-integrity/blob/574b29322b60fc31d5c51f487d4f4a72ebc9d058/vocab/security/vocabulary.yml#L326-L330 defines sec:publicKey to have domain sec:Key. Is that correct or was sec:Key as range intended?

If the domain is sec:Key, what class would its range be? or how would this property be used? An example would help.

If the range is intended to be sec:Key, then PR should follow. I can see it working with the rest of the vocab, e.g.:

<https://csarven.ca/#i>
  sec:publicKey <https://csarven.ca/#key-foo> .
<https://csarven.ca/#key-foo>
  a sec:Key ;
  sec:controller <https://csarven.ca/#i> ;
  sec:publicKeyPem "..." .
bblfish commented 1 year ago

Ah interesting @csarven . On your reading sec:publicKey looks like it would be the opposite relation of sec:controller or close?

csarven commented 1 year ago

Close. sec:controller is for a "particular resource", and not tied to a sec:Key.

Aside: I wonder if sec:publicKey can be equivalent to using keyid with URL as value from HTTP Message Signatures.

msporny commented 1 year ago

Hey @csarven and @bblfish -- at present, sec:publicKey is being deprecated in favor of sec:publicKeyJwk and sec:publicKeyMultibase. Other things, such as sec:publicKeyPem and sec:publicKeyBase58 are also to be deprecated based on the current direction of the Data Integrity specifications:

https://w3c.github.io/vc-data-integrity/#verification-material

Does this create an issue for the way either of you intended to use these properties? To be clear, just because the properties are deprecated, does not mean that we're going to remove them or not define them. It's just that their usage has been (rightly) called into question. Folks seem to be circling around publicKeyJwk and publicKeyMultibase.

We enter Candidate Recommendation in September, at W3C TPAC, so we're trying to clean up these issues that have been lingering out there for a while.

All this to say, what would you like to be done here? What PRs should we raise on the specification given the current state of this section:

https://w3c.github.io/vc-data-integrity/#controller-documents

Perhaps we should just deprecate sec:publicKey? The range of sec:publicKeyJwk should be a sec:JsonWebKey, and the range of a sec:publicKeyMultibase should be a sec:Multikey, and perhaps that's all we say for this round?

bblfish commented 1 year ago

I am fine with sec:publicKeyJWK which I am using in the HttpSig spec, in a KeyDocument such as rfcKey.1.ttl from ReactiveSolid test

<#> a security:JsonWebKey2020 ;
    security:controller </people/alice#i> ;
    security:publicKeyJwk """{
       "alg": "PS512",
       "note": "this is the key from https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-13#page-82. Don't use for real world examples, as the private key is public knowledge",
       "use": "sig",
       "kty":"RSA",
       "e":"AQAB",
       "n":"r4tmm3r20Wd_PbqvP1s2-QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct-Lh1GH45x28Rw3Ry53mm-oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V2pnDOkFV6-U9nV5oyc6XI2w"
    }"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .

I could use a did:key... or did:jwk... and use those in the http header, when I get enough time and funds to implement one of those. But it's good to move step by step, that way one can test each piece.

msporny commented 1 year ago

Ok, we'll implement the suggestion here, then: https://github.com/w3c/vc-data-integrity/issues/74#issuecomment-1620367451

msporny commented 1 year ago

PR #137 has been raised to address this issue. This issue will be closed when that PR is merged.

csarven commented 1 year ago

Is it being deprecated because there isn't adequate implementation experience or deemed to be a faulty design or that alternatives are used more commonly (or something else)?

Manu, do I understand you correctly that sec:publicKey's domain sec:Key is correct?

No, it is not an issue for me (and no objection to the PR) but I would've liked to continue using my existing personal publishing - I am using the ol' wot (and cert) and thought sec and its sec:publicKey would be a simple transition in that I can still use PEM.

I guess I missed the thread on why sec:publicKeyPem is being deprecated.

Let me just say that what I like about referring to the IRI of my key (via sec:publicKey) was that I can link to it from my personal identifier, and that would provide refer to the text value. Tucked away from the human-readable view if I wanted (although the examples of mine above are perhaps don't best illustrate this.) Use of properties like sec:publicKeyJwk or sec:publicKeyMultibase seems to need me to keep this information close my identifier but they wouldn't be particularly useful to most human-readers, and so they force me to hide it from view (although still accessible to machines.)

msporny commented 1 year ago

Is it being deprecated because there isn't adequate implementation experience or deemed to be a faulty design or that alternatives are used more commonly (or something else)?

There has been adequate implementation experience at this point to know that sec:publicKey was not specific enough... the encoding format of the key was desired by implementers to ensure that they didn't have to go to RDF (or sniff the value) to determine the type of key they were dealing with. What ended up sticking, at least for the past couple of years, was publicKey<ENCODED_FORMAT> ... so publicKeyMultibase and publicKeyJwk. So yes, the design was faulty in that implementers implemented things that were more specific, which resulted in the current design, which uses publicKeyMultibase and publicKeyJwk.

Manu, do I understand you correctly that sec:publicKey's domain sec:Key is correct?

Yes.

I guess I missed the thread on why sec:publicKeyPem is being deprecated.

Implementers have either 1) been super cranky and hostile to the property, 2) said that they can express a PEM-encoded key in JWK format, or 3) moved on and started using Multikey since they don't need any of the other features/complexity that PEM-encoded keys bring.

Let me just say that what I like about referring to the IRI of my key (via sec:publicKey) was that I can link to it from my personal identifier, and that would provide refer to the text value. Tucked away from the human-readable view if I wanted (although the examples of mine above are perhaps don't best illustrate this.) Use of properties like sec:publicKeyJwk or sec:publicKeyMultibase seems to need me to keep this information close my identifier but they wouldn't be particularly useful to most human-readers, and so they force me to hide it from view (although still accessible to machines.)

You can still do what you're saying through "verification relationships":

https://w3c.github.io/vc-data-integrity/#verification-relationships

... which are basically ways of saying: "If you need to authenticate me, use this public key"... or "If you need to trust a statement that I have made, use this public key to verify what I said (IOW: I use this public key to issue Verifiable Credentials)."

So, you can still link to your key and express what you could in the past, but more accurately now. Let me know if the above doesn't make sense, but I think we've got you covered wrt. your use cases.

We are headed into Candidate Recommendation in about a month, so we're trying to close down PRs that we believe are addressed. I think we have addressed your question and have updated the spec as much as we can to provide clarity. Let us know if we haven't; I'm going to close this issue now, but feel free to re-open it if you feel like we need to say something more in the spec before we go into CR.

msporny commented 1 year ago

PR #137 has been merged, closing.

melvincarvalho commented 1 year ago

The deprecation of publicKeyPem is highly problematic given its widespread adoption across 10 million fediverse accounts. This action seems inconsiderate of its impact. A reconsideration is advised to avoid significant disruption.

msporny commented 1 year ago

The deprecation of publicKeyPem is highly problematic given its widespread adoption across 10 million fediverse accounts. This action seems inconsiderate of its impact. A reconsideration is advised to avoid significant disruption.

We deprecated the property long ago and conversation in W3C and IETF have not seemed to indicate that people are going to miss publicKeyPem. That said, if folks want us to keep it, it's not a big deal to keep it undeprecated (as long as JOSE folks don't object, which I expect them to object).

If the fediverse folks want us to keep it in the spec and not deprecate it, they're going to have to make that known.

Please open a new issue to track your request to undeprecate publicKeyPem. I hope you will put effort in to demonstrate that the fediverse folks want to keep this property in future iterations of the Data Integrity (and Controller Document) specification. The place to fight for this now is in the Controller Document specification:

https://github.com/w3c/vc-controller-document

Note that the current Data Integrity cryptosuites being worked on by the VCWG allow any compatible key format, as long as it can be translated into something usable by the algorithms in the cryptosuite specifications (publicKeyPem can be translated into something usable by the algorithms, btw).

melvincarvalho commented 1 year ago

IMHO deprecating this property is harmful because it is in wide use. But I will discuss further with fediverse implementers.

I guess I missed the thread on why sec:publicKeyPem is being deprecated.

...

Implementers have either been super cranky and hostile to the property

Do you have a pointer?

silverpill commented 1 year ago

@msporny

If the fediverse folks want us to keep it in the spec and not deprecate it, they're going to have to make that known.

There's a proposal to use Multikey: https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md. However, it won't become widely implemented anytime soon and I expect publicKey along with publicKeyPem to still be a de-facto Fediverse standard 5 years later.

That being said, if deprecation doesn't affect existing implementations, I see no harm in it.

msporny commented 1 year ago

That being said, if deprecation doesn't affect existing implementations, I see no harm in it.

Yes, it's not like ActivityPub will stop working because of this deprecation. The Fediverse community can also choose to ignore the guidance and continue using publicKeyPem, which will then force us to "reflect reality" and undeprecate publicKeyPem.

msporny commented 1 year ago

I guess I missed the thread on why sec:publicKeyPem is being deprecated. Implementers have either been super cranky and hostile to the property

Do you have a pointer?

Yes (the discussion happened over 5+ years), some of the threads are here:

melvincarvalho commented 1 year ago

@msporny, thank you for the insights you've provided; I've taken the time to consider them thoroughly.

Your experience and judgment have always been invaluable, and in the spirit of that wisdom, I would gently urge you to reflect on a principle that seems pragmatic to me, as it likely has to you over our near two decades of acquaintance.

Introducing new methodologies shouldn't necessitate the immediate obsolescence of existing ones. That's at the core of my concern here. The language being used suggests removal, not a gradual deprecation—a distinction that's significant given it's usually a phased process.

It appears there's an oversight regarding the widespread utilization of publicKeyPem within our thriving ecosystem, not to mention the extensive use of base58 and hex-encoded keys. Hex, in particular, is ubiquitous. These formats are still very much in active deployment—I can attest to this firsthand with my recent work involving millions of users in the social web space.

Let's also contemplate, for a moment, the intended flexibility implied by "multi" in multiformats. The existing diversity in formats isn't just historical; it's functional and currently operational. Hex public keys, as a staple in programming, aren't likely to be phased out—you're as aware of this as anyone.

While I recognize that changes can be driven by a consensus, even if that consensus comes from a relatively small and not entirely transparent group of voices, I urge caution. The suggestion that these changes won't have disruptive implications feels somewhat optimistic. After all, if the security vocabulary were so benign in its impact, its presence would be superfluous.

In practice, developers are being guided towards new implementations—such as the one I am working on—which would indeed encounter significant issues without the using for publicKeyPem in my profile JSON.

It's essential to consider the precedent we're setting with standardization practices that may echo economic theories—persuading a group to move from 'eight ways of doing things' down to 'seven.' The influence of majority decision-making is powerful, yet we should be wary of its capacity to overshadow minority needs and existing implementations.

As chair of a W3C group with a user base that includes over 10 million social accounts reliant on straightforward and universally recognized hex public keys, I appeal to your sense of stewardship. Could we ensure that, at the very least, this particular property (hexPublicKey) remains un-deprecated for the foreseeable future?