Redundant step 6 in DPK verification for authentication about webauthn

[agl]

@agl Can you confirm that step 6 is redundant now and can be deleted?

It's step 7 that should be deleted, no? But yes, sorry, I got lost there and it's clearly redundant. I'll do a PR.

[emlun]

Good catch, thanks! I think you're right that step 6 is redundant. It used to be the "else" part of an "if-else" conditional, and the cases now listed in step 5 used to apply only within the "if" branch of that, so step 6 was needed for the "else" branch. But the "if-else" branching was eliminated in commit b92973ce, so step 6 should not be needed anymore.

[emlun]

@agl Can you confirm that step 6 is redundant now and can be deleted?

[ndpar]

While we are in this place of the spec, a couple of things about this paragraph

Otherwise there is some form of error: we recieved a known dpk value, but one or more of the accompanying aaguid, scope, or fmt values did not match what the Relying Party has stored along with that dpk value. Terminate these verification steps.

1. "or fmt" seems to be wrong here, because matchedDpkRecords was built using only aaguid, dpk, and scope for equality. The difference in fmt is covered in the preceding paragraph.
2. It is implied here that during the lifetime of the DPK neither aaguid or scope can change. It is beneficial, I think, to state it explicitly somewhere (my apology if it is and I missed it). Otherwise it is reasonable for an RP to assume that after some platform authenticator update (and maybe certification) the aaguid can change for the existing DPK.

[emlun]

• "or fmt" seems to be wrong here, because matchedDpkRecords was built using only aaguid, dpk, and scope for equality. The difference in fmt is covered in the preceding paragraph.

You're right, the matching and the "Otherwise" description went out of sync in commit 5af393d. I'll add this fix to PR #1858.

2. It is implied here that during the lifetime of the DPK neither aaguid or scope can change. It is beneficial, I think, to state it explicitly somewhere (my apology if it is and I missed it). Otherwise it is reasonable for an RP to assume that after some platform authenticator update (and maybe certification) the aaguid can change for the existing DPK.

I think most would expect that aaguid won't change since that is the case for top-level credentials, so I don't think that needs to be called out more explicitly than the verification steps make it. I would expect scope to be an immutable credential property as well, but I could see a case for adding some mention of this in the CDDL comments defining attObjForDevicePublicKey. But I also think it is unambiguous enough as is. @agl thoughts on this?