Subject: [Secret] BoF Follow-up on charter definition

From: Matthew Byington <[email-masked]>
Date: Tue, 15 Feb 2022 09:22:41 -0800

Hi everyone,

I wanted to thank everyone who participated in our BoF last week. I thought that it went great and all of the comments, questions, and feedback were very useful.

Some folks put up Pull Requests to modify the charter text per our conversation at the BoF (thank you to those that did) and we made some other changes.

I wanted to send the new charter text below and ensure that we’ve captured the feedback appropriately. Please respond to this list if you think that we should make further modifications.

Thanks!
Matt

==============================

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.

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.

Privacy goals include:

	• The relay server should not see sensitive details of the share
	• The relay server should not be able to provision the credential itself, acting as an intermediary for the recipient (MiTM)
	• Aside from potentially the IP address, the relay server should not learn the identity of the sender or receiver

Sufficient security measures should be embedded in the protocol in an effort to:

	• Ensure only the intended recipient is able to provision the credential
	• Ensure the credential can only be provisioned once (Anti-replay)
	• Ensure the sender has intent to share (secure user intent)

The solution the WG comes up with must:

	• Allow a sender to initiate a share
	• Allow a recipient to view the share request, and provision the credential associated with the share upon receipt
	• Allow dynamic message formats based on the credential type
	• Allow sender device and receiver device to quickly perform multiple round trip communications

Out of scope topics for the proposed WG are:

	• Defining the mechanism the receiver will use in order to provision the credential
	• 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.
	• The User Interface (UI) that is displayed to the sender or receiver during sending or receiving - this will depend on the device OEM’s UI and HI guidelines.
The WG will deliver a protocol to facilitate secure credential transfer. The WG must consider all Privacy and Security considerations in an effort to perform the credential transfer in a secure manner. The protocol will use appropriate cryptographic mechanisms to protect the transferred credentials in accordance with the security and privacy goals described above.

==============================

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Feb 2022 16:37:35 -0500

Matthew Byington <mbyington=[email-masked]> wrote:
    > 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.

I still have no idea what it is that we need to share.
It still reads like it's a private **key** to me.

I would love to be able to share a digital hotel key without the hotel's
permission, but I just don't believe that is a real use case today.
For the car, I fear that the car maker is also involved.
I know of no home locks that offer any kind of delegated authorization that
does not require a cloud interface, but I'd sure like a counter-example.

But, if we are dealing with an access/authorization that provides for
delegation, then the digital statement is some kind of document signed by a
key.
It needs privacy because of eavesdroppers, but not because there is a private
key involved.

I think it is critical that the charter include some references.
Maybe it would start with:

  "When digital credential systems such as XXX, YYY, ZZZ are used
  to provide authorization to devices like home door locks, hotel door locks,
  or ignition systems for vehicles, there are often situations where it
  is useful to be able to delegate authorization to another person."

While it is claimed that we don't need to know anything about the systems
involved, and reading about the mailboxes, etc. I can see how that appears to
be the case.  But reading those details re-inforces for me, the view that we
are sharing a private key.

This is one reason I don't think we can start with the proposed ID.
(And as Klensin said: I'm not quite sure why SMTP + SMIME wouldn't be good enough)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide