Provide justification as to why definition of roles should supersede previous industry-accepted definitions

[gmandyam]

In https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture#section-4.1, roles of RP and verifier are defined. RP can only consume attestation results, while verifier can consume attestation evidence. This does not align with the preceding FIDO/Webauthn specification, which enumerates verification as one of the required RP operations: see https://www.w3.org/TR/webauthn-2/#sctn-rp-operations.

The FIDO specification precedes the RATS Architecture document. Therefore the architecture document should contain a detailed justification as to why there is not alignment between the two documents in terms of RP role.

[thomas-fossati]

The way I reconcile this is by interpreting FIDO's RP as an entity combining RATS's relying party (i.e., the RP JS app) and verifier (i.e., the "RP Server") roles.

[gmandyam]

The way I reconcile this is by interpreting FIDO's RP as an entity combining RATS's relying party (i.e., the RP JS app) and verifier (i.e., the "RP Server") roles.

Agreed that this is how one would reconcile the roles definitions.

But that RATS Architecture still lacks justification as to why it is even necessary to reconcile. FIDO was the earlier specification and also had working interoperable implementations before the WG was chartered. The RATS Architecture document should provide a full justification as to why it was necessary to distinguish between the roles of RP and verifier, and attestation results and evidence. It should also state when it is acceptable to use the FIDO definition of RP role and operations, and when the RATS arch. definition should be used. The current draft lacks this guidance.

[thomas-fossati]

The RATS Architecture document should provide a full justification as to why it was necessary to distinguish between the roles of RP and verifier, and attestation results and evidence. It should also state when it is acceptable to use the FIDO definition of RP role and operations, and when the RATS arch. definition should be used. The current draft lacks this guidance.

I'm afraid this request comes a bit too late in the process: the document is currently in AUTH48 state (https://www.rfc-editor.org/auth48/rfc9334).

[gmandyam]

I'm afraid this request comes a bit too late in the process: the document is currently in AUTH48 state (https://www.rfc-editor.org/auth48/rfc9334).

Release from AUTH48 is at AD discretion: see https://www.ietf.org/about/groups/iesg/statements/auth48/.

That being said - why should this prevent us from considering this issue? If the RATS Architecture document is meant to be "authoritative" (as at least per one editor's contention - see ietf-rats-wg/eat#337), then the document should clearly state when the definitions provided in this document should be used in place of other previously-published standards. This could potentially be covered in an addendum as well.

I would also refer back to the charter: https://datatracker.ietf.org/wg/rats/about/: "The WG will continue to cooperate and coordinate with other IETF WGs such as TEEP, SUIT, CoRE, ACE, and CBOR; and work with organizations in the community, such as the TCG, Global Platform, and the FIDO Alliance, as appropriate.". This appears to be a topic where collaboration with organizations such as FIDO and GP was appropriate. Did that occur? Was a review ever solicited from these organization?

[thomas-fossati]

Release from AUTH48 is at AD discretion: see https://www.ietf.org/about/groups/iesg/statements/auth48/.

I think that is not relevant to this case (it refers to the prerogative of the AD to unlock a document under certain conditions rather than blocking its publication.)

But that is irrelevant, what I wanted to say is that for this iteration of the architecture adding changes at this point in time is not really feasible. That of course doesn't preclude us from working on a subsequent update / clarification.

[gmandyam]

But that is irrelevant, what I wanted to say is that for this iteration of the architecture adding changes at this point in time is not really feasible. That of course doesn't preclude us from working on a subsequent update / clarificatio

Agreed. So in that regards this issue should still be considered.

[mcr]

If you have some suggested text, then please suggest it.
Do so before Dec.10 please.

I don't really see why the RATS architecture has any obligation to follow the FIDO/WebAuthN specification.
I'm not even sure that we even contradict what you are saying.

[gmandyam]

I don't really see why the RATS architecture has any obligation to follow the FIDO/WebAuthN specification. I'm not even sure that we even contradict what you are saying.

Maybe it doesn't. That is for the WG to decide. I don't think other documents in the WG (e.g. EAT) have any obligation to follow the RATS Architecture document either.

Will create a PR with suggested text.