Closed kimdhamilton closed 5 years ago
Let's get closure on this one.
It looks like Example 15 was updated to use the RSA 2018 Signature Suite. Perhaps the intent of this is to demonstrate that it can be done with the traditional JOSE/JWS signatures.
In which case, I'd propose we keep the text as is, and change the issue to a note (or something of that form) with a reference to the portion of the document listed here "These concerns will be documented in time in at least the Verfiable Claims Model and Security Considerations section of this document."
It looks like we don't haven't written those concerns yet; I imagine this has to do with the usual items we've discussed, such as algorithmic agility, payload growth for composite claims, etc. I can find a reference.
I'd be happy to take a first stab at this, if this approach makes sense
Note that WebAuthentication is purely CBOR/COSE-based... and that seems to be the direction that this stuff is headed in. So, it raises the question if we want to pull in the JOSE/JWS/JWT stuff when W3C specs aren't pulling it in for WebAuthentication as that spec moves forward.
Chairs will allocate time at TPAC 2018 to discuss this.
From TPAC 2018:
Decision made at Barcelona F2F:
Example 16 in the VC Data Model shows a JOSE/JWT example, followed by this issue:
At RWoT we did some work on aligning JSON-LD signatures with JOSE/JWS. I believe this addressed the concerns mentioned in the above issue; see the LD Signature Format Alignment White Paper for details.
The specific JSON LD signature suite is the 2017 RSA Signature Suite and we created several libraries implementing this. They are listed in the white paper.
Note that the 2017 RSA Signature Suite is based on RFC 7797, the JSON Web Signature (JWS) Unencoded Payload Option specification.
Example:
If this addresses the concerns, I can update the example (using the same claim as in Example 3) and update the surrounding text.