attestation type identifiers and their use is only implicitly defined

[equalsJeffH]

all defined attestation formats contain, in their verification procedure, a statement of this form:

If successful, return attestation type <foo> and <bar> attestation trust path

However, attestation type identifiers are only implicitly defined is the above-cited statements. [note also: the term "attestation type identifier" is not used or defined.]

By combing thru all such above-cited statements, it appears the present set of attestation type identifiers is:

Basic
ECDAA
Self
Privacy CA

The "ECDAA" one is sort of defined in S 6.3.3. Attestation Types.

We ought to formally define all of the attestation type identifiers and appropriately auto-link them to their <dfn>s. Note that PR #741 may add a fifth attestation type of "None".

Also, matching of attestation type identifiers is undefined (i.e. is it case-sensitive or not?), nor their syntax (e.g., is interstitial whitespace allowed? What is the charset allowed?), are defined.

[emlun]

The verification procedures are run wholly within the RP, and the RP can determine the attestation type from the contents of the attestation, so any representation of the attestation type would be used only internally by the RP. Thus there's no need for strictly defined identifiers (because the RP would be both the creator and the consumer of the "returned attestation type") or matching rules for the attestation types.

It seems like a good idea to define and link the terms within the document, but I think that could be regarded an editorial issue.

[selfissued]

Where in the spec where you thinking that the list of types should reside, @equalsJeffH ? Do you agree that this is a strictly editorial indexing exercise?

[equalsJeffH]

@selfissued

Do you agree that this is a strictly editorial indexing exercise?

yes.

[selfissued]

Can you create a PR for this, @equalsJeffH ? Then I'll review.

[equalsJeffH]

see PR #780