Transfer dIGital cREdentialS Securely
charter-ietf-tigress-01

Interesting pieces of work that will be quite useful. Here are some quick comments:

The 1st paragraph is written using "you", I would prefer to read it as the 3rd person.

2nd paragraph, in "Note that neither private keys", the "note that" looks strange in a charter, suggest to replace it by "Note: neither private keys".

The MD format (bullet list) is broken in a couple of places.

It is unclear what "sensitive details of the share" are.

The charter has privacy & security "goals" and "considerations", while I am not a native English speaker, I wonder those 2 words are synonyms. Should 'requirements' be used ?

I agree with Murray's comment that the second paragraph makes it appear a whole lot like the solution is already decided, now all we have to do is figure out how to back into it. :-(

Other than that, my only other comment is that this is the only time I've ever seen an IETF charter feel the need to disclaim device UI considerations. Surely that goes without saying?

The second paragraph reads like a bunch of decisions have already been made.  I suggest this should be rewritten to specify requirements (if that's appropriate at this stage) rather than enumerating things that appear to be properties of an already preferred solution.

I agree with other comment as to whether the requirements/constraints on the solution should be listed in the charter.  E.g., presumably this means that if the WG cannot come up with a solution that meets the constraints then it must close or recharter to progress?


Some of the constraints also seem a little odd, or unclear:

* Allow a sender and a recipient to perform multiple round trip communications within a limited time frame
Is the requirement about performing round trip communications, or to be able to complete the transfer in a short bounded time?

* Not require that both the sender and recipient be online at the same time
What is meant by being online?  Is this about having network connectivity to the relay server?

* Support opaque message content based on the credential type
It wasn't clear to me exactly what this is, or why carrying arbitrary opaque data is an absolute requirement?  Is that about carrying some associated message related to why the credential is being delegated?

Rob

I think the must do things should be part of working group consensus decisions on requirements, and does not need to be part of charter text. The goals seems sufficient to me.