[Secret] AD Review of the proposed charter

[Roman Danyliw <[e-mail]>]

Hi!

Congrats on a successful BoF thanks to the preparation of the proponents and the chairs. The importance of getting both ART and SEC input on this work was voiced on list and during the BOF.  After discussion among the ART-SEC ADs, the resolution was for this work to be administratively housed in the ART area with a SEC AD.  Hence, I'll be picking up this work as the responsible AD.

The next step to get a working group started is to have charter that captures all of the feedback to date.  I heard some charter discussion during the BoF and read more on list.  I reviewed the Feb-22 version I found at https://github.com/dimmyvi/secure-credential-transfer/blob/main/charter.md as the basis for the following comments.  It interleaves my own new feedback and that of the BoF/ML that doesn't appear to be addressed.  

Specific comments on the charter text:

** Paragraph 1. "There are many situations in which it is desirable to share a digital credential with another person. For example, you may want to provide access to your vehicle to a friend or a family member. You may also want to provide access to your home to your cat sitter. Or, you may want to share a hotel key with your spouse. Today, no such standardized method exists in a cross-platform, multidisciplinary capacity."

-- (from BoF) Per "There are many situations in which it is desirable to share a digital credential with another person", there was feedback (Michael Richardson) that this text creates confusion because the WG is in fact focused on delegating, not sharing the credential.

-- (from BoF) The proponents (Matt Byington) in response community feedback (Stephen Farrell) noted that "multidisciplinary" could be clarified

** Paragraph 2.  "The WG charter includes the definition and standardization of a protocol that will facilitate such credential transfers from individual to individual. The protocol will leverage a "relay server" to transfer data from sender to recipient. The scope of the transfer is limited to a single origin device and a single destination device. Note that neither private keys nor secret symmetric keys present on the sender's device are exchanged during the transfer operation. In the transfer protocol, the "credential" being sent from sender to recipient comprises data both necessary and sufficient for the recipient to exchange with the credential authority for new digital key material granting the recipient a subset of the sender's capabilities or entitlements."

-- (from BoF) Ben Kaduk noted that it should be clarified if this is "individual to individual" or "individual+device" to "individual+device" (or user agent) 

** Paragraph 3. "Privacy goals include:
o    The relay server should not see sensitive details of the share
o The relay server should not be able to provision the credential itself, acting as an intermediary for the recipient (MiTM)
o Aside from potentially the IP address, the relay server should not learn the identity of the sender or receiver"

-- In the spirit of inclusive language, please use a different expression than "MiTM"

** Paragraph 4. "Sufficient security measures should be embedded in the protocol in an effort to:
o Ensure only the intended recipient is able to provision the credential
o Ensure the credential can only be provisioned once (Anti-replay)
o Ensure the sender has intent to share (secure user intent)"

-- s/Anti-replay/anti-replay/

** Paragraph 5. "The solution the WG comes up with must: ..."

-- Per "Allow a sender to initiate a share", given that this came up in the BOF discussion, perhaps append "and define the relay server".

-- Per "Ensure the sender has intent to share (secure user intent)", it isn't clear to me what the parenthetical "(secure user intent)" clarifies.

-- Per "Allow dynamic message formats based on the credential type", it was clear to me what "dynamic" means here.  Are the protocol message formats are changing based on the credential type?  Or is it that the protocol will be capable of carrying many different types of credentials (they are opaque blobs, the protocol is agnostic)?

-- Per "Allow sender device and receiver device to quickly perform multiple round trip communications", this came up in the BoF too, is there a way to provide a performance envelope around "quickly".  Is the basis for this CCC and the referenced ISO protocol?

** Paragraph 6. "Out of scope topics for the proposed WG are: ..."

-- s/the proposed WG/the WG/

-- Per "Defining the mechanism the receiver will use in order to provision the credential", I recommend appending "with the credential authority" to reference the notional architecture defined in paragraph 2

-- Per "The WG will define the full set of different credential types that could be shared. A subset of these credential types adhere to a public standard. For these credential types, the format of the Provisioning Information shall be defined by the appropriate standard. Other credential types may be proprietary. For these credential types, the protocol the WG aims to establish shall not define the actual format nor content of each field within the Provisioning Information."

I stumbled on this paragraph because it's listing assumptions, what the WG will do and what is out of scope, all in a bulleted list of what the WG will not do.  I recommend unpacking this.

(a) What does it mean for the WG to "define a full set of different credentials"?  Do you mean that the protocol will have code points?

(b) There is a significance being attached to the credential types being public vs. proprietary which I don't follow.  This is text is also introducing an undefined construct of "Provisioning Information" as a discriminator.  Aren't the credential opaque blobs as far as the protocol is concerned?  Can this please be clarified.

(c) As a proposal for streamlining this text, make this bullet read only about what's out of scope: "Defining the format and setting the values (? contents?) of the credential carried by the protocol"

(d) Perhaps put what the protocol expects in the "The solution of the WG must" paragraph.  I'd like to help wordsmith this but all I can follow is that the protocol has to support credential standards not defined by this WG.  Per (b), the nuance around "provisioning information" should help with the rest.

Other more generic charter comments:

** (from BoF) There were a few comments about bounding the communication channel and distinguishing it from a generic tunnel protocol.  It was explained that this protocol will need to work around the constraints of CCC and a particular ISO spec (I missed which one).  I believe there was a commitment to reference these explicitly.

** What are the milestones that this WG plans to make (as a first pass)?  These need to be explicitly listed - date + milestone.  I would imagine there is the protocol itself (the text says that).  Is there a informational architecture or use case document?  Any profile for a given vertical?  It is fine if the answer is no, but now would be the time to describe it (otherwise it will be out of scope without a recharter).   

Other administrative matters:

** There is a strong signal, which I agree with, that "SECRET" should not be the WG name.  My working understanding from past BOF chair/proponent discussion is that TIGRESS ("Transfer dIGital cREdentialS Securely") is the new proposed WG name.  I'm dropping it here on the list to hear if there are strong objections.  I'd beg the group not to bike-shedding here unless this name is major problem.

** There was a question about why different OAuth approaches couldn't be used.  See https://mailarchive.ietf.org/arch/msg/secret/0VUSVrIRHbRSfEk3uo0BnXJvPpM/.  It would be good to document that on the list.

Regards,
Roman