[webauthn] Refine meaning of ScopedCredentialType to be "signature & assertion format (and version thereof)"

equalsJeffH has just created a new issue for 
https://github.com/w3c/webauthn:

== Refine meaning of ScopedCredentialType to be "signature & assertion
 format (and version thereof)" ==
**Summary:** Refine meaning of ScopedCredentialType to be "signature &
 assertion format (and version thereof)"

**Background:**
See (short three-message) thread beginning here: 
https://lists.w3.org/Archives/Public/public-webauthn/2016Jul/0043.html

>From the initial message in thread from @equalsJeffH :

Subject: CredentialType (was: TAG review feedback: Align Credential  
interface with  Credential Management?

On 7/6/16, 9:05 AM, "Hodges, Jeff" <jeff.hodges@paypal.com> wrote:
> On 7/5/16, 11:59 PM, "Vijay Bharadwaj via GitHub" <sysbot+gh@w3.org>
wrote:
>>- Possibly rename CredentialType to version to make it clearer what
this field signifies (since ScopedCredential is itself arguably a
credential type and ScopedCredentialType is unwieldy)

[ tho Mike West has replied to the original msg, the below is a
tangentially related subitem of the latter ]

the WebAuthentication API <https://w3c.github.io/webauthn/#idl-index> 
is
only about what we've so far called "ScopedCredentials", which have
various overall characteristics such as utilizing asymmetric key 
pairs,
plus associated signature and hash algs, and being scoped to RPs based
 on
eTLD+1.

So I agree with Vijay that we should rename CredentialType. As Vijay 
noted
(on the call today) that someone(s) have mentioned: perhaps it could 
be
used to signify assertions' particular construction aka "signature &
assertion format", in similar fashion to "attestation format". I think
 we
should look into doing that, which inherently incorporates a notion of
"version" because if in the future a particular  "signature & 
assertion
format" is altered, we can assign the new format a new name.

Also, presently, CredentialType (aka SignatureFormat) and
AlgorithmIdentifier (i.e., the cryptographic parameters) are separate
items..
```
  dictionary ScopedCredentialParameters {
      required CredentialType         type;
      required AlgorithmIdentifier    algorithm;
  };
```
..and, AFAICT, the signature format section [1] of the spec is 
orthogonal
to the particular crypto key pair type + sig alg, which are specified 
by
ScopedCredentialParameters.algorithm.

So perhaps we can rename CredentialType to something like
SignatureAndAssertionFormat, and term the present construction as
"ScopedCred1" or something like that..
```
  enum SignatureAndAssertionFormat {
      "ScopedCred1"
  };
```
..where a particular SignatureAndAssertionFormat value signifies a 
given
composition of the clientData, authenticatorData, signature components
 of
a WebAuthnAssertion..
```
  interface WebAuthnAssertion {
       readonly attribute Credential  credential;
       readonly attribute ArrayBuffer clientData;
       readonly attribute ArrayBuffer authenticatorData;
       readonly attribute ArrayBuffer signature;
  };
```
..and "ScopedCred1" represents the specification of the contents of 
those
components as specified in the WebAuthn spec.

What I'd offhand like to try to specify is something like (borrowing 
from
TLS presentation language here (RFC5246)..
```
  interface Credential {
      readonly attribute SignatureAndAssertionFormat sigAssnFmt;
      readonly attribute BufferSource                id;
  };

  interface WebAuthnAssertion {
      readonly attribute Credential  credential;

      select from credential.sigAssnFmt {

          case "ScopedCred1":       // defined in WebAuthn Level 1 
spec
              readonly attribute ArrayBuffer clientData;
              readonly attribute ArrayBuffer authenticatorData;
              readonly attribute ArrayBuffer signature;

          case "...":               // defined in <fill-in-here> spec
              ...;
      };
  };
```
..but I don't know whether and how to do that in proper webidl.
thoughts?
=JeffH
[1] https://w3c.github.io/webauthn/#signature-format


>From final message in thread from @equalsJeffH :

On 7/7/16, 1:02 AM, "Vijay Bharadwaj" <vijaybh@microsoft.com> wrote:
>One way to do this would be to use inheritance - define a base type
WebAuthnAssertion with just a credential member and then derive
interfaces from it with additional members as needed.

gotcha.

>Another way would be to define the assertion as having type any, and
specify in the text of the spec how the type is determined based on 
the
AssertionFormat

yeah like we're doing with WebAuthnAttestation.statement.

I guess either would work. I'm not sure of the longer-term tradeoffs.
since we're already using one of the approaches, perhaps we should 
re-use
that approach for consistency?


>AssertionFormat (how do you feel about this shortened name btw?).

works for me as long as we clearly indicate that it encompasses all of
 sig
format and contextual data content & formats.

If we were using abbreviated names in the API, I would name it
SigAndAssnFormat, but we're not doing that...

=JeffH





Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/296 using your GitHub account

Received on Sunday, 6 November 2016 17:19:10 UTC