[{"author": "Pete Resnick", "text": "

She said something at the beginning about not doing \"protocol\" or the like, but instead that they were only doing \"api\". Did I get that wrong?

", "time": "2022-07-27T19:09:35Z"}, {"author": "Matt Byington", "text": "

@Pete what she meant was that we aren't trying to describe a specific communication protocol, but more at one layer higher to facilitate the steps that need to happen (APIs) to actually achieve the share.

", "time": "2022-07-27T19:10:00Z"}, {"author": "Richard Barnes", "text": "

i solve these problems by living in an apartment building with a front desk :)

", "time": "2022-07-27T19:10:04Z"}, {"author": "Matt Byington", "text": "

Meaning - whether HTTP is used or not for the actual API calls isn't the question, if that makes sense.

", "time": "2022-07-27T19:10:18Z"}, {"author": "Pete Resnick", "text": "

@Matt Byington Thanks, that's what I missed.

", "time": "2022-07-27T19:10:31Z"}, {"author": "Matt Byington", "text": "

No problem at all.

", "time": "2022-07-27T19:10:35Z"}, {"author": "Eric Rescorla", "text": "

Is there a link to the draft? I don't see one in the meeting materials link

", "time": "2022-07-27T19:12:24Z"}, {"author": "Nick Sha", "text": "

https://datatracker.ietf.org/doc/draft-secure-credential-transfer/

", "time": "2022-07-27T19:12:38Z"}, {"author": "Samuel Weiler", "text": "

I'm not hearing the word \"permissionless\", and I was hoping that was part of the requirements. I'm concerned about RPs interjecting themselves - and stopping the functionality that end users need.

", "time": "2022-07-27T19:12:40Z"}, {"author": "Matt Byington", "text": "

@Eric https://datatracker.ietf.org/doc/html/draft-secure-credential-transfer-04

", "time": "2022-07-27T19:12:55Z"}, {"author": "Matt Byington", "text": "

@Samuel \"RP\"?

", "time": "2022-07-27T19:13:08Z"}, {"author": "Samuel Weiler", "text": "

relying party. e.g. the hotel or apartment manager (in the form of the lock on the room or apartment door), in their examples

", "time": "2022-07-27T19:13:42Z"}, {"author": "Matt Byington", "text": "

Ah got it. Yes. So typically the RP in typical crypto scenarios is the one verifying the signature for example, in this case it's a little different IMHO - you have sender and receiver, and you have the credential authority themselves. This would be the issuer of the credentials. They have to be \"trusted\", but we should prevent MITM (intermediary) attacks, for sure.

", "time": "2022-07-27T19:14:39Z"}, {"author": "Richard Barnes", "text": "

Seems like we should not be re-doing the BOF here

", "time": "2022-07-27T19:15:49Z"}, {"author": "Justin Richer", "text": "

I thought this :was: the BoF

", "time": "2022-07-27T19:16:07Z"}, {"author": "Bradford Lassey", "text": "

its a WG now

", "time": "2022-07-27T19:17:00Z"}, {"author": "Samuel Weiler", "text": "

@Justin Richer they were chartered a week and a half ago

", "time": "2022-07-27T19:17:02Z"}, {"author": "Matt Byington", "text": "

We did a BoF a few months ago, Justin (virtual). The WG is defined and established now.

", "time": "2022-07-27T19:17:10Z"}, {"author": "Leif Johansson", "text": "

correct - this is not a BoF

", "time": "2022-07-27T19:17:13Z"}, {"author": "Kristina Yasuda", "text": "

sounds like authorization/delegation protocol is (mis-)called a transfer protocol

", "time": "2022-07-27T19:17:15Z"}, {"author": "Richard Barnes", "text": "

virtual bof a little while ago https://datatracker.ietf.org/wg/tigress/about/

", "time": "2022-07-27T19:17:23Z"}, {"author": "Leif Johansson", "text": "

the purpose of the presentation is to make sure everyone has a chance to catch up with the problem description

", "time": "2022-07-27T19:17:30Z"}, {"author": "Justin Richer", "text": "

Thanks everyone -- I saw that bof but thought this was the WG-forming bof. I got it now!

", "time": "2022-07-27T19:17:49Z"}, {"author": "Richard Barnes", "text": "

DKG is having more eventful hotel stays than i am

", "time": "2022-07-27T19:17:55Z"}, {"author": "Roman Danyliw", "text": "

Richard Barnes said:

\n
\n

virtual bof a little while ago https://datatracker.ietf.org/wg/tigress/about/

\n
\n

The BOF that led to this WG was named SECRET -- https://datatracker.ietf.org/wg/secret/meetings/

", "time": "2022-07-27T19:18:18Z"}, {"author": "Carsten Bormann", "text": "

\"justified parties\" (Kim Cameron)

", "time": "2022-07-27T19:21:20Z"}, {"author": "Roman Danyliw", "text": "

Kristina Yasuda said:

\n
\n

sounds like authorization/delegation protocol is (mis-)called a transfer protocol

\n
\n

Indeed. We spent significant time bike-shedding the name after the BoF.

", "time": "2022-07-27T19:22:48Z"}, {"author": "Roman Danyliw", "text": "

Leif Johansson said:

\n
\n

the purpose of the presentation is to make sure everyone has a chance to catch up with the problem description

\n
\n

Thank you for starting this meeting with this introduction to level set what we agreed to in the charter.

", "time": "2022-07-27T19:23:50Z"}, {"author": "Roman Danyliw", "text": "

The relay server is a foundational piece of the architecture written into the charter.

", "time": "2022-07-27T19:24:58Z"}, {"author": "Richard Barnes", "text": "

relay server is just necessary for async, right? so that the sender and receiver don't have to be online at the same time

", "time": "2022-07-27T19:25:07Z"}, {"author": "Matt Byington", "text": "

Yes.

", "time": "2022-07-27T19:25:13Z"}, {"author": "Matt Byington", "text": "

And because you don't want a cryptographic key sent in an SMS, too ;)

", "time": "2022-07-27T19:25:19Z"}, {"author": "Matt Byington", "text": "

(Or a secure channel - you don't want the end users to see that material, from a UX perspective)

", "time": "2022-07-27T19:25:40Z"}, {"author": "Roman Danyliw", "text": "

Richard Barnes said:

\n
\n

relay server is just necessary for async, right? so that the sender and receiver don't have to be online at the same time

\n
\n

Agreed. In the charter we said \"* Not require that both the sender and recipient have connectivity to the relay server at the same time\"

", "time": "2022-07-27T19:26:03Z"}, {"author": "Matt Byington", "text": "

Precisely, yes, concur.

", "time": "2022-07-27T19:26:19Z"}, {"author": "Roman Danyliw", "text": "

The charter says we don't want replay attacks so \"* Ensure the credential can only be provisioned once (anti-replay)\"

", "time": "2022-07-27T19:26:58Z"}, {"author": "Jonathan Rosenberg", "text": "

Does this mean the link sent to the receiver is a one-time-use link?

", "time": "2022-07-27T19:27:50Z"}, {"author": "Richard Barnes", "text": "

JDR: that's my understanding, that that's effectively the goal here

", "time": "2022-07-27T19:30:18Z"}, {"author": "Matt Byington", "text": "

JR: Mostly yes. but we do want to allow that specific receiver to retry (for example for read time outs). if that makes sense?

", "time": "2022-07-27T19:31:05Z"}, {"author": "Pete Resnick", "text": "

He's not asking why you want to prevent replay. He's asking how it's possible to do a replay attack.

", "time": "2022-07-27T19:31:14Z"}, {"author": "Kristina Yasuda", "text": "

where in the draft is the \"thing\" that the receiver sends to the provisioning authority being defined?

", "time": "2022-07-27T19:32:49Z"}, {"author": "Kristina Yasuda", "text": "

can't find it

", "time": "2022-07-27T19:32:56Z"}, {"author": "Eric Rescorla", "text": "

@Kristina Yasuda it's just some opaque blob defined

", "time": "2022-07-27T19:35:00Z"}, {"author": "Matt Byington", "text": "

Kristina: For stateless, this would be the bearer token effectively that travels with the provisioning data to the receiver, via the relay server. For stateful, like cars that comply with CCC, it'd be the receiver providing their asymmetric public key to the sender who then signs it. with an attestation. because cars are \"local\" credential authority.

", "time": "2022-07-27T19:35:06Z"}, {"author": "Jim Fenton", "text": "

Sounds like provisioning the link between car owner and valet on the relay server would be tricky.

", "time": "2022-07-27T19:35:57Z"}, {"author": "Jim Fenton", "text": "

since they don't have more than a very ephemeral relationship

", "time": "2022-07-27T19:36:18Z"}, {"author": "Matt Byington", "text": "

How so? The relay server is mostly a \"dumb pipe\". The \"sender\" here, the owner of the car, would simply sign the key with the attestation stating it is for valet privileges only.

", "time": "2022-07-27T19:36:27Z"}, {"author": "Mallory Knodel", "text": "

Lots would be left to implementers. Really important that this WG thinks about guardrails.

", "time": "2022-07-27T19:36:34Z"}, {"author": "Matt Byington", "text": "

Mallory: that's true. I agree with that.

", "time": "2022-07-27T19:36:51Z"}, {"author": "Brent Zundel", "text": "

What is being sent? The actual secure credential itself, or a way to get an actual secure credential?

", "time": "2022-07-27T19:44:33Z"}, {"author": "Matt Byington", "text": "

The latter, Brent, but pedantically a way to get a newly-minted secure credential with the appropriate ACLs.

", "time": "2022-07-27T19:44:52Z"}, {"author": "Brent Zundel", "text": "

So, I can share my car key as long as the provisioning server (which is out of scope) agrees?

", "time": "2022-07-27T19:45:42Z"}, {"author": "Brent Zundel", "text": "

Maybe this will be answered by the architecture overview...

", "time": "2022-07-27T19:46:17Z"}, {"author": "Jabber", "text": "

dkg: i'm pretty sure that a piece of paper has a replay attack

", "time": "2022-07-27T19:46:17Z"}, {"author": "Matt Byington", "text": "

Car key is a little different since you own the car you can technically share the credential without the vehicle OEM at all, since you own the private key to the car as the user. But in short, yes

", "time": "2022-07-27T19:46:33Z"}, {"author": "Matt Byington", "text": "

Jabber: that's the thing, the point is that you could technically share that widely (the paper) but only the first one who \"claims\" it is the only one allowed in.

", "time": "2022-07-27T19:47:01Z"}, {"author": "Matt Byington", "text": "

(preventing the replay specifically of the redemption)

", "time": "2022-07-27T19:47:17Z"}, {"author": "Brent Zundel", "text": "

But if I wanted to share my car key without involving the OEM, would I need to then set up my own provoking server?

", "time": "2022-07-27T19:47:42Z"}, {"author": "Jabber", "text": "

dkg: Matt Byington -- how do we ensure that car owners do actually retain this level of ownership?

", "time": "2022-07-27T19:47:56Z"}, {"author": "Brent Zundel", "text": "

*provisioning lol

", "time": "2022-07-27T19:48:05Z"}, {"author": "Matt Byington", "text": "

provoking == relay, yes.

", "time": "2022-07-27T19:48:11Z"}, {"author": "Eric Rescorla", "text": "

@Brent Zundel that would indeed be a provoking server!

", "time": "2022-07-27T19:48:36Z"}, {"author": "Matt Byington", "text": "

dkg: that's by design and codified in the CCC vehicle digital key standard

", "time": "2022-07-27T19:48:37Z"}, {"author": "Matt Byington", "text": "

(that the owner of the car owns the private key).

", "time": "2022-07-27T19:48:48Z"}, {"author": "Brent Zundel", "text": "

Okay, so I send the secure credential I control to the relay, then send access to the relay to the entity with whom I'm sharing the key.

", "time": "2022-07-27T19:49:23Z"}, {"author": "Matt Byington", "text": "

Yes, Brent, exactly. Now - this is still pending the \"allowlist\" discussion from a few minutes ago, given that your relay may not be trusted by sender or recipient

", "time": "2022-07-27T19:50:09Z"}, {"author": "Matt Byington", "text": "

For example, large device OEMs will likely use a relay server for shares that they are in control of and host.

", "time": "2022-07-27T19:50:59Z"}, {"author": "Jabber", "text": "

mcr: if I have a fat channel between sender/receiver can I just share a did: or ni: URL and avoid the relay server entirely?

", "time": "2022-07-27T19:52:12Z"}, {"author": "Jabber", "text": "

dkg: as i understand it, the credential owner (the authority) must be online, even if the sender and recipient are not synchronously online. is that right?

", "time": "2022-07-27T19:53:28Z"}, {"author": "Matt Byington", "text": "

mcr: yes that would work. as long as whatever operating system on sender and receiver supported that, also. no reason that wouldn't work.

", "time": "2022-07-27T19:54:21Z"}, {"author": "Jabber", "text": "

dkg: requirements: problem statement, assumptions, constraints, threat model

", "time": "2022-07-27T19:54:23Z"}, {"author": "Matt Byington", "text": "

dkg: yes, correct, for remote credential authorities (like a hotel key). specifically they have to be online when the sender initiates the share and again online when the receiver attempts to redeem it (and to provision the credential on the recipients device) but not technically in between.

", "time": "2022-07-27T19:55:06Z"}, {"author": "Jabber", "text": "

dkg: so in the case where the authority (the owner) is the sender (my understanding of the car owner model), the requirement for offline access is moot, because the sender must be online in their role as the owner.

", "time": "2022-07-27T19:56:12Z"}, {"author": "Jabber", "text": "

dkg: is that right?

", "time": "2022-07-27T19:56:27Z"}, {"author": "Jabber", "text": "

mcr: dkg, alas, in the car case, you are (DRM) not the owner, as far as I can tell.

", "time": "2022-07-27T19:56:40Z"}, {"author": "Jabber", "text": "

dkg: mcr: that's not what Byington claims above (\"codified in the CCC\")

", "time": "2022-07-27T19:57:06Z"}, {"author": "Matt Byington", "text": "

dkg: precisely. you're spot on. they'd have to be online initially to initiate the share. now, they could go offline, while the recipient is offline. then, recipient goes online, generates asymmetric key pair, and sends the public part of that key pair BACK to sender to sign, through relay. now, the protocol \"waits\" until sender is back online, signs the receiver's public key, and put the signature back onto relay to send to recipient. that's the \"back and forth\" and why the relay is needed in the first place.

", "time": "2022-07-27T19:57:17Z"}, {"author": "Matt Byington", "text": "

For car: The Vehicle Owner is the credential authority. But it != Vehicle OEM

", "time": "2022-07-27T19:57:44Z"}, {"author": "Jabber", "text": "

mcr: that's good news.

", "time": "2022-07-27T19:58:20Z"}, {"author": "Matt Byington", "text": "

(that signature, from sender/owner of the car, is really what the car cryptographically NEEDS for the receiver's key to work).

", "time": "2022-07-27T19:58:20Z"}, {"author": "Jabber", "text": "

dkg: mcr: i'm sure that there will be some fuzziness w.r.t. rental cars, leased cars, company cars, etc.

", "time": "2022-07-27T19:58:45Z"}, {"author": "Matt Byington", "text": "

It then uses chain of trust not dis-similar to SSL CAs to see \"do I trust this key? no. hmm. but it's signed by the owner's key, which I do trust. so you're good to go\"

", "time": "2022-07-27T19:58:52Z"}, {"author": "Jabber", "text": "

mcr: and the bank that loaned the money to buy the car!

", "time": "2022-07-27T19:59:02Z"}, {"author": "Matt Byington", "text": "

Yes. In those cases, the rental car company is the owner of the car. YOu'd need to get the share from them. And your key wouldn't contain privileges that would allow you to further share the credential.

", "time": "2022-07-27T19:59:28Z"}, {"author": "Jabber", "text": "

dkg: right, we've already got ignition lockouts used by collections companies

", "time": "2022-07-27T19:59:34Z"}, {"author": "Jabber", "text": "

dkg: so if you've rented a car, and you find you've had one too many, you can't give your friend the keys to drive you home without the rental car company knowing about it.

", "time": "2022-07-27T20:00:58Z"}, {"author": "Matt Byington", "text": "

They could just use your phone?

", "time": "2022-07-27T20:01:24Z"}, {"author": "Matt Byington", "text": "

Which already has the credential. Spatial locality is guaranteed (since it's a car).

", "time": "2022-07-27T20:01:36Z"}, {"author": "Matt Byington", "text": "

Plus, you should have planned ahead better! don't bring your car in the first place. drinking and driving takes too many lives. but that's a different problem not covered in this WG.

", "time": "2022-07-27T20:02:09Z"}, {"author": "Nick Sha", "text": "

dkg: rental cars and fleet management usecase definitely will require a more thoughts at the CCC credential level

", "time": "2022-07-27T20:02:22Z"}, {"author": "Kristina Yasuda", "text": "

probably a mailing list conversation, but suggest to rename \"mailbox\" as it's misleading. it's something that the user can delete any time and there will be as many mailboxes as there are receivers which does not match general association of \"mailbox\"

", "time": "2022-07-27T20:02:25Z"}, {"author": "Matt Byington", "text": "

@Kristina: noted

", "time": "2022-07-27T20:03:03Z"}, {"author": "Brent Zundel", "text": "

I like \"dead drop\"
\nMakes me feel like a spy.

", "time": "2022-07-27T20:03:11Z"}, {"author": "Pieter Kasselman", "text": "

Pushing responsibility to the user for making a trust decision is something we see being exploited in authorization protocols/cross device protocols. General suggestion here is that the protocols should (1) minimise the trust decisions the user makes (e.g. make it hard for the attacker to initiate the request) (2) provide the necessary information to the user to make good decisions (location, reputation etc of requestor) and (3) help the user recover from poor trust decisions.

", "time": "2022-07-27T20:03:13Z"}, {"author": "Jabber", "text": "

dkg: \"you should have planned better\" is not very satisfying to someone who didn't plan, or whose life didn't happen according to their plan.

", "time": "2022-07-27T20:03:15Z"}, {"author": "Matt Byington", "text": "

dkg: agreed, was a bad joke. my original statement still stands that the car is still drive-able from the friend as long as you're in the car with the phone.

", "time": "2022-07-27T20:03:45Z"}, {"author": "Pieter Kasselman", "text": "

A threat model that takes into account social engineering attacks will help in the design and also help implementors in avoiding some of the social engineering attacks that may happen.

", "time": "2022-07-27T20:04:16Z"}, {"author": "Matt Byington", "text": "

@Pieter: I fully concur with your statements there, potentially vehemently. It will be critical to explain what you are sharing and what it grants the recipient in whatever UI is drawn. definitely.

", "time": "2022-07-27T20:04:28Z"}, {"author": "Jabber", "text": "

dkg: is spatial locality part of this spec? or just something that you expect to happen during provisioning or some other out-of-scope arrangements?

", "time": "2022-07-27T20:04:51Z"}, {"author": "Matt Byington", "text": "

dkg: specifically not required for sharing. you should be able to share to a recipient anywhere, they shouldn't need to be close to you.

", "time": "2022-07-27T20:05:25Z"}, {"author": "Matt Byington", "text": "

(other than if you use a comm. mechanism that requires it like blueTooth, NFC, ZigBee, Z-wave, etc)

", "time": "2022-07-27T20:05:39Z"}, {"author": "Samuel Weiler", "text": "

this system does not add any new revocation capabilities for these new credentials, right? we're left with whatever exists already in the credential scheme? so if it's not good at revoking creds now, this doesn't help?

", "time": "2022-07-27T20:05:45Z"}, {"author": "Tim Cappalli", "text": "

Proximity woudl likely influence UI presentation to the user, but not the protocol.

", "time": "2022-07-27T20:05:52Z"}, {"author": "Matt Byington", "text": "

Tim C: agreed.

", "time": "2022-07-27T20:06:03Z"}, {"author": "Pieter Kasselman", "text": "

Matt Byington said:

\n
\n

@Pieter: I fully concur with your statements there, potentially vehemently. It will be critical to explain what you are sharing and what it grants the recipient in whatever UI is drawn. definitely.

\n
\n

Some of the work we are doing on cross device flows may be useful as you think about this problem. We need to design for Homo Sapiens, not Homo Securitus ;)

", "time": "2022-07-27T20:06:22Z"}, {"author": "Matt Byington", "text": "

Samuel W: yes that's right. we do think revocation is critical. but it needs to happen between sender and credential authority

", "time": "2022-07-27T20:06:24Z"}, {"author": "Justin Richer", "text": "

proximity would affect the security context of the protocol in use though.

", "time": "2022-07-27T20:06:26Z"}, {"author": "Jabber", "text": "

dkg: Byington: i think that makes sense -- by the same token, the authority could require arbitrary other constraints during the issuance step, right?

", "time": "2022-07-27T20:06:34Z"}, {"author": "Matt Byington", "text": "

dkg: yep. agreed.

", "time": "2022-07-27T20:06:51Z"}, {"author": "Richard Barnes", "text": "

the WG name notwithstanding, the presence of credentials in this scheme is kind of irrelevant. this is basically SMS + Bron Gondwana's self-encrypting URLs

", "time": "2022-07-27T20:06:56Z"}, {"author": "Matt Byington", "text": "

@Justin R: yes that is true

", "time": "2022-07-27T20:07:01Z"}, {"author": "Pete Resnick", "text": "

For very small values of \"read\"...

", "time": "2022-07-27T20:07:19Z"}, {"author": "Benjamin Kaduk", "text": "

Viktor conveniently doesn't mention that the existing way to integrate GSS-API and HTTP is quite unfortunately structured...

", "time": "2022-07-27T20:08:09Z"}, {"author": "Jabber", "text": "

dkg: Barnes: i am also not seeing why this is \"credentials\". it's a three-party (or two-party) handshake.

", "time": "2022-07-27T20:09:00Z"}, {"author": "Kristina Yasuda", "text": "

+1 to what Eric is saying

", "time": "2022-07-27T20:11:08Z"}, {"author": "Leif Johansson", "text": "

(with chair-hat off) I remember the oauth2 BoF when multiple people noted striking similarities with Kerberos

", "time": "2022-07-27T20:11:30Z"}, {"author": "Bradford Lassey", "text": "

All of those chat applications need to be modified to do this GET to display the preview to begin with

", "time": "2022-07-27T20:11:43Z"}, {"author": "Bradford Lassey", "text": "

so the...yea, what Barnces just said

", "time": "2022-07-27T20:11:58Z"}, {"author": "Jabber", "text": "

mcr: any good design is worth repeating :-)

", "time": "2022-07-27T20:11:58Z"}, {"author": "Matt Byington", "text": "

@Bradford pretty much all of them do the GET already today. You can test it for yourself. That's pretty standard to show rich previews (for example when people share websites to each other)

", "time": "2022-07-27T20:13:54Z"}, {"author": "Tim Cappalli", "text": "

I see it more as a voucher system than a messaging system.

", "time": "2022-07-27T20:15:08Z"}, {"author": "Pete Resnick", "text": "

What is the non-generic part of the protocol?

", "time": "2022-07-27T20:15:15Z"}, {"author": "Jabber", "text": "

mcr: the trick is to disguise my house key credentials as a cat picture.

", "time": "2022-07-27T20:15:28Z"}, {"author": "Pete Resnick", "text": "

@Tim Cappalli Sure, the system isn't generic, but what about the underlying protocol is not generic?

", "time": "2022-07-27T20:16:25Z"}, {"author": "Richard Barnes", "text": "

to be clear, i think this approach is fine, i just think it could be stated more reusably

", "time": "2022-07-27T20:18:11Z"}, {"author": "Kristina Yasuda", "text": "

For the draft, would be good to clarify the use-cases for stateful protocol

", "time": "2022-07-27T20:19:02Z"}, {"author": "Prachi Jain", "text": "

Kristina Yasuda said:

\n
\n

For the draft, would be good to clarify the use-cases for stateful protocol

\n
\n

Noted !!

", "time": "2022-07-27T20:19:27Z"}, {"author": "Kristina Yasuda", "text": "

thanks! right now, hard to imagine why stateless one is not enough

", "time": "2022-07-27T20:19:56Z"}, {"author": "Kristina Yasuda", "text": "

(PS looks like there are no notetakers..?)

", "time": "2022-07-27T20:20:22Z"}, {"author": "Matt Byington", "text": "

Kristina: The main thing is when the sender needs something from the recipient. That's what it boils down to. In that case, since you can't guarantee both are online at same time, hence stateful.

", "time": "2022-07-27T20:20:23Z"}, {"author": "Matt Byington", "text": "

\"Needs something\" == for example needs a newly-minted public key from the recipient that the sender needs to sign

", "time": "2022-07-27T20:20:52Z"}, {"author": "Leif Johansson", "text": "

@kristina - PaulHoffman is taking notes but probably offline

", "time": "2022-07-27T20:21:12Z"}, {"author": "Jabber", "text": "

dkg: i thought the difference was whether there was a distinct credential server involved

", "time": "2022-07-27T20:21:16Z"}, {"author": "Kristina Yasuda", "text": "

right so sender can pre-obtain it or obtain it after initiating sending - a diagram would help

", "time": "2022-07-27T20:21:19Z"}, {"author": "Jabber", "text": "

dkg: did i misunderstand those diagrams?

", "time": "2022-07-27T20:21:32Z"}, {"author": "Kristina Yasuda", "text": "

@leif, yeah this page is blank: https://notes.ietf.org/notes-ietf-114-tigress

", "time": "2022-07-27T20:21:35Z"}, {"author": "Matt Byington", "text": "

dkg: you are right. they sort of go hand in hand. whenever you have a symmetric credential the sender is never the authority. i'm conflating the two for brevity.

", "time": "2022-07-27T20:22:10Z"}, {"author": "Leif Johansson", "text": "

I am sure Paul is doing it using his favorite 3d markdown editor or something

", "time": "2022-07-27T20:22:27Z"}, {"author": "Jim Fenton", "text": "

Of course, relay server has visibility to IP addresses of sender and receiver.

", "time": "2022-07-27T20:23:43Z"}, {"author": "Justin Richer", "text": "

I don't think this answer is aligning with the question. It's sounding like the question is about how to abuse the relay server, not about how to trust it.

", "time": "2022-07-27T20:23:58Z"}, {"author": "Tim Cappalli", "text": "

Aside: The FIDO cross-device authentication architecture is very similar to this, especially the \"sender\" > relay server relationship component.

", "time": "2022-07-27T20:24:12Z"}, {"author": "Jabber", "text": "

mcr: If the relay server becomes available for sharing cat pictures, then there is, I guess, a risk that it will be used for distribute of child porn or other illegal material, and it seems that we are doing a lot of work here to avoid that. The corollary is that we don't want the relay server to have to ever look at what's stored there, because we are trying not to trust the relay server with access to the credential.

", "time": "2022-07-27T20:24:50Z"}, {"author": "Matt Byington", "text": "

Justin: It's worth noting the relay must be open to the internet with regard to ingress traffic but that doesn't mean it isn't doing authentication of the sender.

", "time": "2022-07-27T20:24:57Z"}, {"author": "Justin Richer", "text": "

@Matt what's the authentication layer look like?

", "time": "2022-07-27T20:25:16Z"}, {"author": "Pete Resnick", "text": "

The more interesting question to me is whether there is much new work to be done here or could technology we've already got be adapted to do what's needed?

", "time": "2022-07-27T20:25:46Z"}, {"author": "Kristina Yasuda", "text": "

(personally, at least at this point it sounds like stateless protocol is enough and stateful protocol is an overkill for what it is meant to do - which is fairly narrowly scoped)

", "time": "2022-07-27T20:25:55Z"}, {"author": "Matt Byington", "text": "

Justin: It could be proprietary for someone who doesn't want their relay server used more widely for sending. We define different authentication mechanisms in the draft.

", "time": "2022-07-27T20:26:03Z"}, {"author": "Jabber", "text": "

mcr: Are there IPR or other reasons why the entire Connected Car Credential protocol can't/isn't coming to the IETF? We could use that for many things.

", "time": "2022-07-27T20:26:28Z"}, {"author": "Matt Byington", "text": "

Kristina: since you don't have both parties online at the same time (or rather can't guarantee that) you must have state.

", "time": "2022-07-27T20:27:00Z"}, {"author": "Jabber", "text": "

mcr: @Pete like HTTP PATCH, POST, and all the WebDAV Stuff, right?

", "time": "2022-07-27T20:27:15Z"}, {"author": "Samuel Weiler", "text": "

once again, I want permissionless delegation.

", "time": "2022-07-27T20:30:12Z"}, {"author": "Kristina Yasuda", "text": "

@Matt receiver can retrieve \"token\" from the mailbox any time - that is orthogonal to sender obtaining additional info after pushing that \"token\" to the mailbox

", "time": "2022-07-27T20:30:33Z"}, {"author": "Mallory Knodel", "text": "

The relay servers are doing a lot of critical work in this design. Something I raised in my review of the WG charter was the unlikelihood that the relay server is truly an independent third party. Ecosystem/implementations question to follow through about as this progresses.

", "time": "2022-07-27T20:30:34Z"}, {"author": "Kristina Yasuda", "text": "

that's why current stateful/stateless definition is kind of misleading, no?

", "time": "2022-07-27T20:30:50Z"}, {"author": "Matt Byington", "text": "

Kristina: I don't disagree but I fear we are missing each other's point. It might be my fault. I am trying to respond to a lot of the messages

", "time": "2022-07-27T20:31:05Z"}, {"author": "Kristina Yasuda", "text": "

yesh, thanks for responding

", "time": "2022-07-27T20:31:19Z"}, {"author": "Jim Fenton", "text": "

In practice, I expect Hilton will use Hilton's relay server, Schlage will use Schlage's, GM will use GM's. It will be hard wired into the vendor's key sharing app.

", "time": "2022-07-27T20:31:21Z"}, {"author": "Matt Byington", "text": "

@Mallory: Relay doesn't have to be a third party so I don't disagree with you. It could be owned and operated by the same as the sender.

", "time": "2022-07-27T20:31:36Z"}, {"author": "Tim Cappalli", "text": "

if you go to get a new hotel key at the front desk, you need to show ID and that is likely logged. I don't see the difference here.

", "time": "2022-07-27T20:31:52Z"}, {"author": "Pete Resnick", "text": "

@mcr: I think there's work to be done here, but it sounds more like a profile on, e.g., WEBDAV, which might be less work. Or not; I could be convinced either way.

", "time": "2022-07-27T20:31:54Z"}, {"author": "Matt Byington", "text": "

Jim F: that is certainly a tenable state of affairs and I don't see an issue there.

", "time": "2022-07-27T20:31:54Z"}, {"author": "Kristina Yasuda", "text": "

@Jim if relay server is managed by the credential authority, now it has to establish trust with the sender

", "time": "2022-07-27T20:31:57Z"}, {"author": "Matt Byington", "text": "

pedantically it could establish trust in some way. it could also choose to be open and sans auth.

", "time": "2022-07-27T20:33:08Z"}, {"author": "Jim Fenton", "text": "

@Kristina The relay server has to establish trust with the sender in any case. But typical users will trust the hardcoded one because they don't have any knowledge of relay servers at all.

", "time": "2022-07-27T20:34:04Z"}, {"author": "Eric Rescorla", "text": "

@Tim Cappalli when I checked i I got two keys and I can give the second one to anyone

", "time": "2022-07-27T20:34:04Z"}, {"author": "Jabber", "text": "

mcr: As long as I have to use the Hilton App, and not a generic wallet+secure-enclave, then there is no point in standardization :-)

", "time": "2022-07-27T20:34:08Z"}, {"author": "Tim Cappalli", "text": "

Eric Rescorla said:

\n
\n

Tim Cappalli when I checked i I got two keys and I can give the second one to anyone

\n
\n

Sure, but in this model, you're not sharing an existing key. It is the equivalent of going to the front desk and getting another one.

", "time": "2022-07-27T20:34:34Z"}, {"author": "Jabber", "text": "

dkg: so wait, to borrow a key from a friend who has a Schlage lock, i have to install a Schlage app on my mobile device?

", "time": "2022-07-27T20:34:46Z"}, {"author": "Tim Cappalli", "text": "

It is a derived credential in many ways.

", "time": "2022-07-27T20:34:50Z"}, {"author": "Jabber", "text": "

mcr: @dkg, Jim said that, not me.

", "time": "2022-07-27T20:35:04Z"}, {"author": "Eric Rescorla", "text": "

@Tim Cappalli but again, I can get another key and give it to someone but the hotel doesn't know who I gave it to

", "time": "2022-07-27T20:35:09Z"}, {"author": "Matt Byington", "text": "

Tim C / mcr: the equivalent will exist in this protocol. Hilton (the credential authority) would limit you from sharing your key to the number of people you put on your hotel reservation.

", "time": "2022-07-27T20:35:25Z"}, {"author": "Tim Cappalli", "text": "

Eric Rescorla said:

\n
\n

Tim Cappalli but again, I can get another key and give it to someone but the hotel doesn't know who I gave it to

\n
\n

you can also just give your phone to someone else...

", "time": "2022-07-27T20:35:26Z"}, {"author": "Matt Byington", "text": "

(analogous to your \"front desk\" example, same deal)

", "time": "2022-07-27T20:35:32Z"}, {"author": "Eric Rescorla", "text": "

@Tim Cappalli well, I think those are pretty different

", "time": "2022-07-27T20:35:46Z"}, {"author": "Tim Cappalli", "text": "

are they though?

", "time": "2022-07-27T20:35:54Z"}, {"author": "Jabber", "text": "

mcr: but, as EKR just said, they don't actually do that today.

", "time": "2022-07-27T20:35:58Z"}, {"author": "Mallory Knodel", "text": "

Would assume there are some existing apps that use Bluetooth or airdrop and don\u2019t even bother with servers. Does this protocol work in that case?

", "time": "2022-07-27T20:36:01Z"}, {"author": "Eric Rescorla", "text": "

Yes, they are different, in part because the keys are separate from all my other stuff

", "time": "2022-07-27T20:36:18Z"}, {"author": "Richard Barnes", "text": "

seems like this OpenGraph stuff invites abuse. definitely implementing that on my next phishing campaign

", "time": "2022-07-27T20:36:21Z"}, {"author": "Bradford Lassey", "text": "

dkg: I think the answer depends. If schlage requires you to have the app to use the key then yes. If schlage lets the crediential live in apple wallet and google wallet then you can send it via sms withough the schlague app

", "time": "2022-07-27T20:36:57Z"}, {"author": "Matt Byington", "text": "

certainly it's an avenue of abuse. totally agree.

", "time": "2022-07-27T20:37:02Z"}, {"author": "Matt Byington", "text": "

@Bradford is spot on , I think.

", "time": "2022-07-27T20:37:13Z"}, {"author": "Jim Fenton", "text": "

@bradford But you probably needed to have the schlage app to open your own front door in any case.

", "time": "2022-07-27T20:38:26Z"}, {"author": "Jabber", "text": "

mcr: keybox.

", "time": "2022-07-27T20:39:11Z"}, {"author": "Bradford Lassey", "text": "

@Jim, that's a product decision for Schlage to make

", "time": "2022-07-27T20:39:23Z"}, {"author": "Matt Byington", "text": "

@Jim not necessarily at all.

", "time": "2022-07-27T20:39:33Z"}, {"author": "Richard Barnes", "text": "

dead drop

", "time": "2022-07-27T20:39:36Z"}, {"author": "Bradford Lassey", "text": "

but it is possible to do without a schlage app

", "time": "2022-07-27T20:39:40Z"}, {"author": "Cullen Jennings", "text": "

I think mailbox is a pretty common term used in messaging space for this

", "time": "2022-07-27T20:39:54Z"}, {"author": "Richard Barnes", "text": "

yeah, \"mailbox\" or \"dropbox\" are pretty standard

", "time": "2022-07-27T20:40:09Z"}, {"author": "Kristina Yasuda", "text": "

personal data store rather

", "time": "2022-07-27T20:40:24Z"}, {"author": "Pete Resnick", "text": "

@Cullen Jennings But \"mailbox\" tends to be a long lived entity. In this model, they're ephemeral.

", "time": "2022-07-27T20:41:42Z"}, {"author": "Matt Byington", "text": "

They do live for as long as the stateful transfer needs to take. could be 30 days for example.

", "time": "2022-07-27T20:42:14Z"}, {"author": "Matt Byington", "text": "

(depending on the online/offline of the sender and receiver)

", "time": "2022-07-27T20:42:25Z"}, {"author": "Matt Byington", "text": "

if everyone is online, yes it would be fast and mostly ephemeral.

", "time": "2022-07-27T20:42:39Z"}, {"author": "Jim Fenton", "text": "

Would the mailbox (or whatever) typically be delete-on-retrieval?

", "time": "2022-07-27T20:43:11Z"}, {"author": "Cullen Jennings", "text": "

@Pete - fair but acutaly, I think these do live for hours to days so that is long lived in my world. ( but none of this is a big deal as long as they define whatever term they use )

", "time": "2022-07-27T20:43:38Z"}, {"author": "Matt Byington", "text": "

Jim: yes on completion (since could be more than 1 retrieval )

", "time": "2022-07-27T20:43:55Z"}, {"author": "Pete Resnick", "text": "

(NB: The name of this thing is mostly a \"bikeshed\" question. But yes, @Cullen Jennings , it is fine if well defined.)

", "time": "2022-07-27T20:44:32Z"}, {"author": "Jim Fenton", "text": "

@matt I don't understand the more than 1 retrieval case.

", "time": "2022-07-27T20:44:54Z"}, {"author": "Matt Byington", "text": "

for example a read time out, relay thinks it is done (wrote bytes to socket) but receiver has to retry (broken pipe) or otherwise. also, for stateful, the receiver would download information twice: once to get the sender's info and then again to download sender's signature.

", "time": "2022-07-27T20:45:34Z"}, {"author": "Cullen Jennings", "text": "

I think part of confusion here is what the apps on the mobile device is.

", "time": "2022-07-27T20:45:41Z"}, {"author": "Justin Richer", "text": "

It's not just going to be confusion, it's going to be a whole world of lock-in per relay server, like Jim was saying.

", "time": "2022-07-27T20:46:05Z"}, {"author": "Jim Fenton", "text": "

@matt thanks

", "time": "2022-07-27T20:46:10Z"}, {"author": "Justin Richer", "text": "

you'll receive it and your software will just say \"no\"

", "time": "2022-07-27T20:46:18Z"}, {"author": "Cullen Jennings", "text": "

Is it the hilton app, it is apple wallet, and how does it put things in and out of whatsapp. I can imagine how I would implement it and it might be right but probably drawing that all out would help people undertand

", "time": "2022-07-27T20:46:35Z"}, {"author": "Matt Byington", "text": "

makes sense Cullen we can work on that. it could be any of the ones you just listed.

", "time": "2022-07-27T20:46:58Z"}, {"author": "Brandon Weeks", "text": "

@Cullen Jennings from what I can tell, commenters seem to want to control the relay server, whereas app developer are going to control the relay server.

", "time": "2022-07-27T20:47:04Z"}, {"author": "Jim Fenton", "text": "

Problem with not being able to choose relay server might be if the provider goes out of business and relay server disappears. Can't share credentials then,

", "time": "2022-07-27T20:48:02Z"}, {"author": "Brandon Weeks", "text": "

That problem stems from proprietary app stores, if Schlage goes out of business, you're buying new locks.

", "time": "2022-07-27T20:49:49Z"}, {"author": "Justin Richer", "text": "

It's the allowlist for the receiver, we can't legislate that being a user choice from an RFC.

", "time": "2022-07-27T20:50:30Z"}, {"author": "Pete Resnick", "text": "

Examples are good.

", "time": "2022-07-27T20:51:04Z"}, {"author": "Roman Danyliw", "text": "

We have a number of different options on documenting requirements -- in a skeleton solution draft, in a draft we use but don't adopt, update the charter now that we learned more, etc. We'll sort it out.

", "time": "2022-07-27T20:52:13Z"}, {"author": "Roman Danyliw", "text": "

Same answer if we also need examples or use cases documented.

", "time": "2022-07-27T20:53:00Z"}, {"author": "Roman Danyliw", "text": "

Same answer if we need a upfront threat model.

", "time": "2022-07-27T20:53:37Z"}, {"author": "Pete Resnick", "text": "

Sounds like a lot of people want to start with a fresh document.

", "time": "2022-07-27T20:56:50Z"}, {"author": "Benjamin Kaduk", "text": "

Using voting to assess consensus is not a great way of doing it, either...

", "time": "2022-07-27T20:58:14Z"}, {"author": "Roman Danyliw", "text": "

Thanks for all of the input for this first meeting.

", "time": "2022-07-27T20:58:48Z"}]