search

ietf-rats-wg / architecture

RATS Architecture
Other
15 stars 10 forks source link

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

Open gmandyam opened 1 year ago

gmandyam commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/ietf-rats-wg/eat/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.