DISPATCH Virtual Meeting @IETF-112

Monday 8 November 2021
12:00-14:00 UTC

MeetEcho
Notes
Jabber

DISPATCH Meeting

Status and Agenda Bash - Chairs and ADs (5 min)

Secure Credential Transfer (20 min)

Presenter: Matt Byington
draft-secure-credential-transfer
Messages

Flextime (35 mins)

ART AREA Meeting

BoFs, updates and meetings of interest - ADs (10 min)

ART Area Review Team (ART-ART) & Internationali(s|z)ation (10 min)

Presenter: Barry Leiba / John Klensin

AOB (40 minutes)

Minutes

Kirsty did the Note Well, the Note Very Well, and some background on how best to work with meetecho.

Secure Credential Transfer

Matt Byington presenting (first time IETFer)

• Lots of discussion in chat

OpenGraph is a very popular protocol.

Questions:

Patrick running the queue. Reminds everybody that dispatch is for deciding where to work on things.

Patrick McManus: What is the deployment status?

• There have been meetings between some companies around this topic so far. This is a cross-platform sharing mechanism which would need to be adopted by OEMs.
• It’s not shipping yet, but there’s definitely plans to match these goals.

Pete Resnick:

Phillip Hallam-Baker: why not use SAML? It exists, it’s a standard which is designed to do exactly this.

• May not be familiar with this, can you please describe.
• PHB: it’s an OASIS standard, based on PKIX. Flexible assertion format. Applies to Authentication and Authorisation. Widely used in enterprises. It’s how enterprise software talks to each other.
• A: Main architectural piece that’s missing is that there needs to be a server that relays messages to get around communication channel restrictions.
• A: Will look into it

Samuel Weiler:

• Looks like problems also been looking at in WebAuthN. Might help with device and migration problems.
• Don’t see how this works with hardware based tokens.
• Not hearing “permissionless” - e.g. would need Auto OEM to get involved.
• Not sure how revocation works.
• Think there’s interesting problems here, would like to see progress
• Suggest: BOF to work on requirements.

Stephen Farrell:

• Think it’s an interest idea, think presentation doesn’t show problem space is worked out well
• Not sure if BOF or WG - but would like to work on requirements first.
• Don’t want to work on a system which requires an operating system overlord (Android, IOS) to be involved.

RESPONSE:

• on revocation: once receiver has provisioned a credential, assume communication channel doesn’t exist. So there revocation would be through the credential authority itself.
• Credential Authority needs to keep a graph of shares on its side.

ekr:

• it’s hard to reverse engineer the requirements from the design!
• seem to be solving the easy problem (once a secure channel, how do we get detail over it?)
• place to start is pretty clear statement of the requirements case.
• A: that makes sense, got it. Will try to document requirements further.
• A: think the experience for the receiver is important
• A: a UUID will bind (item 4 to item 5) on first connect. Could have a low TTL.
• ekr: think a design document “here’s the parties, here’s the setup”
• ekr: this design seems to have a lot of lock - there should be ONE message format, and everybody needs to be able to receive it.

Richard Barnes:

• this should be a working group. Don’t think the clarity is here yet regarding what this group would be doing or what problem it would be solving. Think there’s something worthwhile to work on here.
• Question of trust establishment needs to be established.
• If there’s no security at the bottom, there’s no security at all. Need to be super-crisp about what we assume about that channel and the identiy of the sender/recipient.
• Quick question: wonder why this mechanism is framed about credentials? This could be a general sync protocol for sending data securely between systems.
• A: concur, this could really be generic. Don’t think it’s a good system for “sync” - ongoing persistant data. It’s a “one-shot send”.
• A: photos etc - apple has AirDrop, etc. Make this as simple as that. Want it to work across platform. Hotel key, etc. Sender able to revoke, see who they shared it with, etc.

Cullen Jennings:

• am strongly interested in this, but the problem isn’t standardising the relay server - it’s solving the whole slide.
• A: when you look at existing devices, they have existing methods for inserting credentials into devices already. The issue is that the ways Apple/Google do it are proprietary.
• A: back compat issue would be very hard for these systems.
• yeah, but you’re taking that on anyway.
• Patrick: a BOF?
• Cullen: expect so.
• Matt: this credential authority knows how to provision data on both systems.

Rich Salz (with Pete’s question):

• Question: are you OK with the IETF tearing up what you’ve done and changing it entirely?
• Good question; there are large actors in this ecosystem that endeavour to build a soultion which solves some of the outlined problems. If it solves the same goals and is compatible with how these things have to work in the credential authority space. We need to define something that plays into the existing systems.
• So: it depends.
• Looking forward to discussing it in detail - if it’s better than what’s here and solves the same problems, we might adopt it.

Patrick as chair:

• dispatch sometimes sees work that wants to receive a rubber stamp for an existing protocol, which is not how the IETF works.
• hearing that you have requirements, but not a locked-in protocol.
• A: also timing - academically waiting for the right answer is good, but often these companies want to launch a solution that solves this problem. There are a lot of driving factors. If we can do it on short order, then OK - but if it takes a year or 2 or 3, then it would proceed without the IETF’s work.

Ted Hardie (via email):

• Think this needs a lot of work. WG would be appropriate.

Thanks everybody who made comments.

Chairs will give feedback at the end of the session.

ART section

Francesca presenting meetings of interest

Murray: MEDIAMAN is looking for a co-chair. Please contact Murray.

Francesca: likewise, pleaese get in touch if you want to chair - we’re always looking for chairs.

Barry Leiba: also SCIM working group has been re-opened.

ARTART is now operational, and has done around 30 reviews which have been very helpful for the ADs.

ECMAScript Media Types Updates In Last Call (ends 2021-11-15)
https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

ART AD Office hours are today.

Side meetings are an option: https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings

Nomcom is open for feedback.

I18N

Barry Leiba - sometimes we come up with things in the ARTART review where internationalization might be required (how strings are compared / used where human readable)

Don’t need you to become an expert, just see flags of when it might need review.

Robert Sparks via chat: the trick is noticing when it needs something, but is absent.

John Klensin: there’s a balance problem. There are fundamental issues.

• questions when non-ascii

1. Why?
2. If free-text, saying “just use UTF-8” is not enough.

John via chat: Barry and I should have added that, if anyone has expertise in the i18n area and who is not already involved in the directorate/ review activities, we would love to hear from you (Barry and/or Pete are the best contact points)

Anyone who isn’t already an ARTART reviewer and wants to help, please let Barry know!

Media over QUIC

Spencer Dawkins presenting

Side meeting on Tuesday.

AOB?

DISPATCH OUTCOME

Kirsty: consensus for first draft - consensus was BOF on problem space, scope out use-cases.

Cullen: please clarify - requirements around relay, or around the whole problem?

Patrick: concur that we should address the question of how much of the whole problem is in scope.

• App community might drive scope, sec community drive design of components.

Francesca: conversation can continue on the dispatch or art mailing list while we coordinate with SEC ADs and proponents.

Richard Barnes: don’t think it belongs in sec - the interesting questions are around the broader architecture. The details of the crypto needs to be arranged properly, but we can bring in exepertise. The work belongs in ART not SEC.

outcome: Francesca will chat with SEC ADs.

Suggestions via chat: virtual interim BOF – too long to wait until next IETF.