Skip to content

Latest commit

 

History

History
164 lines (144 loc) · 13.4 KB

agenda.md

File metadata and controls

164 lines (144 loc) · 13.4 KB
Raw

JWS test suite meetings for C&C WG

hackmd-github-sync-badge

Note: If you are viewing this on github and it seems out of date, try clicking the above link, hackmd may hold more recent content not yet approved/cleaned by WI editors/WG chairs for syncing to github archival records.

{ Meeting Recordings }

1/31

Agenda:

  • Tooling nits - CEL is on the job
  • future of the group? Stay in DIF or make a VCWG2.0 note?
    • Mike: I'd like a broader participation of course
    • Orie: VCWG test suite v1 didn't even verify signatures; they moved raw crypto verification out of scope (yikes)
    • Russian doll: this suite lets you assume (and verify) proof types per key type, WHETHER USING JSONLD OR NOT... the VCWG should maybe follow that model?
    • Mike: Doesn't the draft charter include test suites? Orie: Yes, but W3C doesn't really define that for us... we need to set the bar high...
  • VCWG Scope Issues
    • charter#43
      • Mike: what API
      • Scope of VC-API and VPReq Spec?
      • Mike: Trust model of verifier<>issuer? What knowledge does this API assume in the issuer?
      • Orie: In VC-API, issuer flows as currently specified can't handle OIDC-style semi-trusted issuer service use-cases, for example... I've been pushing for a long time
      • Orie: putting representations on equal footing

1/17

Agenda:

  • RSA and P-384?
  • update on addition to/instead of text and vectors

1/3 - no meeting, proceed over github

12/20

  1. Updates
    • upstream PR on msft implementation opened as discussed last week
    • pull #36: finish integrating msft implementation
    • test vector refinements:
      • more explicit testing of outputs; define per vector inputs
      • better vectors
      • better visualizations - how to mark addition to/instead of choices per property?
        • counts? charts?
    • recommendations for VC-JWT (and VC WG 2.0)
      • spotlighting divergence to roadmap convergence
    • bookkeeping: sign off on grant?
    • JWS-LDP test suite

12/6

  1. Updates
    • LD/JWT roundtrip test vector added
    • Microsoft test driver v1 built (and reviewed by CEL)
  2. Microsoft
    • Driver
      • id not optional (set by default if not by construction of builder object)
      • expiration not optional (set by default if not by construction of builder object)
    • step by step (or rather, prop by prop) tour of how MSFT library takes in a credential and makes it a VC
      • default iss<id is a random UUID (breaks v1.1 conformance)
      • datetime hijinx
        • is issuanceDate poorly named? there's an open data model v2 issue
        • proof.created date (can be set manually for test vectors) <> iat mapping (vc data model issues 809)
      • iss (must be string) <> issuer (which can be an object, with issuer.id as a string if LD object like all the examples in the spec); use-case of whether to drop issuer.id as redundant after moving to iss
        • negative test vector - redundant fields (iss and issuer.id) are different and the WRONG ONE is used
    • uPort/DIF implementation drops redundancies dropping line here (good catch, Cel!)
  3. wishlist for vc data model v2
    • more precise definition of verificationMethods and signature resolution
    • verification not defined (partic around round-trip/redundant props between payload and JWT envelope)
      • i.e. negative test vector - redundant fields (iss and issuer.id) are different and the WRONG ONE is used in verification (or, as Orie put it, validate before verify)
  4. next steps
    • visualize results better (partic normative statements) than red/green
      • "instead of"
      • failures

11/22

  1. CI
  2. VC-JWT update
    • RSA added by Spruce (Transmute might some day later?)
    • expected behavior - Charles and Orie discussed over github, and I think we could run the suite over a MSFT credential
      • discuss issues about w3c data model spec conformance in this group?
      • cross-representation loss of information ("instead of")
Detailed minutes
  • VC data model #828
    • example JWT for discussion
    • See this PR discussion for context
    • Date issues fixed by VC spec 1.1 - one remains, tho: unix timestamp versus ISO8610 datetime (can incl. leap seconds) - limits roundtrip translation (Orie: only possible with "in addition to path"/mapping in JWT - see here)
      • For backward compatibility with JWT processors, the following registered JWT claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts:
      • TransMute goes "in addition to"; DChadwick went "instead of"; MSFT and uPort went "instead of"
      • Mike: UNIX time format ignoring leapseconds is a historic simplification that has bedeviled IAM for decades... seems a problem in theory but not in practice to me
      • Orie: but it can break signatures!
      • Mike: Timekeeping has been simplified by industry standards, tho... are we creating problems by overriding that?
      • Mike: Write a note about industry time representations, and how to destroy leapseconds
    • Orie: there's another example of where round-trip translation isn't possible: complex objects in LD VCs, e.g. trace-vocab#example-59
      • CEL: mapping issuer.id to iss, no?
      • Mike: there's a practical solution... Orie: But the "instead of" is hard to make reproducible or unambiguous across implementations
      • Orie: if not-before loses leap seconds, that's not a big deal.
      • iss field: iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation. in the JWT section of the VC spec, this is assumed to be a string, but a complex object is valid in an LD-VC...
    • For practical purposes, maybe we tackle timestamp issuers and more semantically consequential things like iss separately? and thirdly also deal separately with external proofs
      • In the type theoretical sense, what is a credential and a presentation? Is iss part of the credential, or only part of the verifiable credential (when you transform it and attach the proof)? regardless of assertion format, we all start from a credential and pick an assertion format to transform it into...
      • Mike: What didn't make it into vc1.1?
        • Orie: We preserved VC and VP terms in IANA, but couldn't map to anything registered in IANA; ambiguities about the mandatory fields of a JWT versus mandatory fields of a VC
        • David, on that thread: jwt.payload.vc is an "intermediate representation" that, when combined with an external proof, becomes a VC
  • Summary:
    • this test suite will go the "in addition to" route and document how implementations CAN preserve information across representations; this can serve as evidence but not as argument for later VC WG v2 conversations about "in addition to/instead of" cross-representation decisions

10/8

  1. Discussion of vc-jwt strawman and test vectors
  2. Detailed discussion of s-curve versus S-curve issue
    • other projects have already run into the problem
    • This test suite/repo is not the place to propose a solution or a norm, much less dictate where/who normalizes to it
    • Action item: Orie will outline/freewrite the core of a blog post about the upstream ambiguity and what would fix it, Juan will edit it to DIF blog post status to help get eyes/pressure on the problem and direct both to the appropriate venue(s)

9/27

  1. codewalk of suite repo, how to use, current state of design issues to date
  2. recruiting implementor-testers
  • orie will reach out to securekey
  • spruce will dogfood - ours has a P-384 bug to fix, but otherwise works
  • markus: we have a java implementation that supports some key types
    • Markus: I think I understood the codewalk, I'm sure we can make it work (works like VC-HTTP-API v1, right? Orie: Yeah!)
  1. sidebar: discussion of testing logistics - how to make local implementation setup simple enough not to distract or create barrier to users using this suite
  2. evaluation criteria discussion:
    • one option: local verify CLI option + self-issued: OIDF test suite took this option and it works well I think; SAML self-testing was quite hard, for lack of this kind of mechanism
    • desire expressed to use did-key and sidestep "did method politics"
    • stability of test vectors:
      • cryptographers prefer very stable and deterministic outputs (nonces, dates, etc)- where possible, people
      • p256 and P384 cannot freeze those, entropy required; therefore, we can stabilize Ed25519 for people that want to do that
      • self-issued: for comparison, here are the JOSE test vectors
        • Orie: RFC 7520 was a huge accelerator of adoption and alignment; good test vectors go a long time
      • Orie: Stable test vectors better than usable test vectors, I think;
    • Q and A
      • Markus: maps to verificationMethods?
      • Private key representations: how closely to bind to public key representations? (Pertinent to LDP work)
        • Self-issued: I think it's quite impractical to stray from representations
        • Test vectors could force this issue by making JWKs, rather than vM-style key representations/paths, the form taken in the test vectors to highlight the issues of linking them
        • Universal Wallet follows the convention used in this draft so far
        • CEL: WebCrypto? Orie: Not exactly-- it lets you export priv and/or pub JWKs;
        • Orie: WebAuthN seems to rely on/assume a priv key representation similar to the one used in CCG work items...
        • CLI tool could resolve Pubkeys from VCs "somehow" (assuming vM resolution); implementations need to handle that, and have freedom of doing various ways
      • Including verification conformance would force this issue, but taht seems out of scope for now for the grant so I'd rather defer on that...
    • Relation of this signature suite to JWTs
      • codewalk of Transmute's approach
        • note: kid is set to key.id because issuer is CONTROLLER, not necessarily vM, in VC-JWT
        • self-issued: MSFT would be happy if this created a way to test "normative VC-JWTs"
        • Orie: Yes, transmute agrees-- this test suite could test a "normative VC-JWT" as an opt-in profile
        • self-issued: we would support increasing the scope to make this a profile of VC-JWT explicitly
        • Markus: DanubeTech also supports a VC-JWT -- but i'm worried there could be a little messaging/marketing confusion - JWS assumes RDF canonicalization and VC-JWT doesn't - pretty different signing mechanisms -
          • Markus: This needs to be documented clearly somewhere to avoid that confusion
          • Orie: input to credential-create op can and should be identical, even if signing mechanisms are different
          • Group consensus to include that section to the deliverable, BUT ALSO agrees it will be very hard to explain and write
  3. Next steps
  • Orie: I will put aformat parameter in the for loops in the next iteration, to include that VC-JWT profile
    • @Context sidebar: input vectors should be valid as LD
  • Markus: VC-API support?
    • Orie: I'd love for that work item to adopt some form of this? if this work is done in time, I would like to propose it to the next batch of test vectors there to support a 3rd proof type (JWS, BBS+, and LDP)
      • Orie: I think that JWS2020 and did-key are almost 100% identical, thus redundant... confusing CCG naming convention
      • CEL: RSA? Orie: Yeah, this suite could also support that key type, if
  1. (If time allows) Healing JWT