Procedures update for optional features #158
Conversation
| </li> | ||
| <li> | ||
| If |featureOption| equals `"baseline"`: |
There was a problem hiding this comment.
I think we might want to shorten this to just feature (or another single word name like "mode" or something that we come to consensus on), but I wouldn't hold up this PR for it. I think this PR is an approvement and am in support.
There was a problem hiding this comment.
Hi @dlongley, agree. Picking good names is hard. Currently have a lot of names with option in it. Simpler the better.
| </ol> | ||
| </li> | ||
| <li> | ||
| If |featureOption| equals `"anonymous_holder_binding"`: |
There was a problem hiding this comment.
Using snake_case here is inconsistent with our other names, so I'd prefer it be camel case or hyphenated (or whatever else matches our current style elsewhere), but again wouldn't hold up the PR for that.
There was a problem hiding this comment.
Hi @dlongley, this is a bit of a mess and extends to variable names, and the IETF specs too (mixing camel and snake case). I would be nice to choose camel or snake case (or whatever) throughout or have a established naming convention for functions, variable, constants, constant strings, etc. I'm more than happy to clean up everything according to a nice convention. Does W3C have anything written? I'm not strongly optioned on what the conventions should be.
…g inputs, outputs and such for issuer, holder, and verifier.
…y inputs and steps.
…ns and return different items based on headers.
…tep that calls serialization.
…header bytes and output serialization.
…nd to return a featureOption field.
…r, and formatting improvements. Co-authored-by: Ted Thibodeau Jr <[email protected]>
…r, and formatting improvements. Co-authored-by: Ted Thibodeau Jr <[email protected]>
msporny
force-pushed
the
procedures-update
branch
from
7f94fbf
to
c41cd4e
Compare
Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
Normative, multiple reviews, changes requested and made, no objections, merging. |
This PR addresses issues: #153, #156 and also #150 and #157.
It does this by clarifying which optional feature, if any, is being used via an
featureOptionvariable, feature specific base proof and derived proof header bytes, and extending procedure/function descriptions to clarify inputs/outputs. In addition informative summary tables have been added to the section describing the optional features.Note that some optional features are dependent on IETF APIs that are yet to be frozen. These have been notated.
Preview | Diff