[Cbor] Re: CDDL: Can .within apply to groups?

[Carsten Bormann <[e-mail]>]

Hi Emil,

TLDR: No.

> This question is prompted by a couple of discussion threads in WebAuthn (issue 2210, PR 2219): can the CDDL .within control operator apply to groups?

No, as Section 3.9 of RFC 8610 says:

3.8.  Controls

   A _control_ allows relating a _target_ type with a _controller_ type
   via a _control operator_.

The two occurrences of the word “type” may be inconspicuous, but they are really part of the definition of the “control” construct.

> The current WebAuthn L3 editor's draft (and previous versions of it) includes the following CDDL declarations:
> 
> Section 5.7.3:
> AuthenticationExtensionsAuthenticatorInputs = {
>   * $$extensionInput .within ( tstr => any )
> }

As you found, that doesn’t even work syntactically, for the reason given above:

Expected one of " ", ";", "\n", "\r\n", "...", "..", ".", "/", ")" at line 2, column 37 (byte 85):
  * $$extensionInput .within ( tstr => any )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

You could cheat the grammar like this:

AuthenticationExtensionsAuthenticatorInputs = {
  * $$extensionInput .within within
}

within = ( tstr => any )

but then you’ll get a semantic error (abbreviated):

> > $$extensionInput not a type [:grpchoice]

We could start a discussion about whether CDDL should be extended with group controls, but maybe what you need right now is a short-term solution.

A start for a good change proposal is right within https://github.com/w3c/webauthn/issues/2210:

> 1. Inline the .within control operator into the attObj definition:
> attObj = {
>     authData: bytes,
>     $$attStmtType
> } .within attStmtTemplate  ; Every attestation statement format must have the fields below

I don’t quite understand the item 2 in this proposal; if the objective is to check all map entries to be within `( tstr => any )` , you can write (note the added `*`, because we don’t want exactly one extension, but any number of them, including zero):

attObj = {
    authData: bytes,
    * $$attStmtType
} .within { * tstr => any }

$$attStmtType //= (foo: bar)
$$attStmtType //= (baz: bat)

This creates the following examples (using

    cddlc -tcddl fragment.cddl | CDDL_INVENT=a cddl - gp 10

...to work around a parser limitation in the original cddl tool and to “INVENT” any rules that are defined outside this snippet):

/attObj/ {"authData": /bytes/ h'726F64656E74', "foo": /bar/ "a-bar",
 "baz": /bat/ "a-bat"}
/attObj/ {"authData": /bytes/ h'686973746F72696F6C6F676963616C',
 "foo": /bar/ "a-bar", "baz": /bat/ "a-bat"}
/attObj/ {"authData": /bytes/ h'7265666F63696C6C6174696F6E',
 "foo": /bar/ "a-bar"}
/attObj/ {"authData": /bytes/ h'737465636B6C696E67', "baz": /bat/ "a-bat"}
/attObj/ {"authData": /bytes/ h'6F646F6E7461677261', "foo": /bar/ "a-bar",
 "baz": /bat/ "a-bat"}
/attObj/ {"authData": /bytes/ h'636F6C6C696E656172697479'}
/attObj/ {"authData": /bytes/ h'6F7A6F7068656E65', "baz": /bat/ "a-bat",
 "foo": /bar/ "a-bar"}
/attObj/ {"authData": /bytes/ h'70726F6D696E656E746C79', "baz": /bat/ "a-bat",
 "foo": /bar/ "a-bar"}
/attObj/ {"authData": /bytes/ h'73746F6B65686F6C65', "baz": /bat/ "a-bat",
 "foo": /bar/ "a-bar"}
/attObj/ {"authData": /bytes/ h'6175746F746F6D6963', "baz": /bat/ "a-bat",
 "foo": /bar/ "a-bar"}

If you add

$$attStmtType //= (1: bat)

… to the CDDL fragment, you get some error indications from the examples generated by the above.

> Therefore my question: can .within apply to groups?

See above.
I hope that my suggestion is useful.

> Or am I missing something, is there some other way to express what we want?

Given that in your specific case the mandatory entries of the map also conform to the structure that is to be checked by the .within, this is easy to convert to checking a type.

This doesn’t answer the general question on whether a future revision of CDDL should have group controls.  I haven’t had much time yet to think about the semantic implications; it seems to be easy to generate example models for this that might hurt, but maybe we just don’t need to write specs that hurt.  

Thank you for bringing this use case to the attention of the WG; this is very useful input.

Grüße, Carsten