Web Authentication WG -- 25 May 2016

<vgb> hi, sorry i'm late

<weiler> hakim, who is here?

<selfissued> Mike Jones here, but still downloading WebEx

<weiler> 8 present. 8 total on the call.

tony: On today's agenda, status of blog post, publication, and open issues for the next draft
... discussion about extensions
... some people have made review passes through the document
... and registration for TPAC F2F in Lisbon
... AOB?

FPWD

tony: we called consensus for FPWD on Monday
... hearing no objections
... we also gave Mike Jones action to write blog post

<Zakim> vgb, you wanted to discuss update on fpwd editorial prep

<selfissued> I've circulated a blog post to the chairs and W3C reps

<selfissued> Received two pieces of feedback that I'll incorporate

<selfissued> Wendy asked whether the blog post wants to talk about future timeline

SamSrinivas: I sent some comments

<selfissued> Once I'm on WebEx (still downloading) let's talk about that

<selfissued> Yes - Sam - I agree with your comments and will incorporate

<selfissued> (WebEx download at 53% :-( )

vgb: the link-checker reports 404, on FIPS reference, there's a PDF there though
... and a second 404 at the /TR link, since that doesn't yet exist
... also bikeshed boilerplate lacked FPWD status. I'm happy to add it to the HTML manually
... since we'll never have another FPWD

wseltzer: we can deal with those 2 404s; the /TR is expected

JeffH: we need to fix the shortname in the metadata

vgb: I can send a tarball to weiler
... I'll check the shortname into the repo
... in bikeshed, you can manually override on the command line

weiler: We'll publish next Tuesday, May 31
... sounds as though we're on track
... webmaster publishes Tuesdays and Thursdays

tony: blog post at the same time?

weiler: we will make that happen at the same time

selfissued: I will send to the list; I was going to incorporate SamSrinivas's change (not "passwordless" but reducing reliance on password)
... Wendy had suggested a forward looking statement about our timeline for CR
... but I was concerned about guessing about dates

tony: it helps people understand we're on a rapid pace, when they need resources for implementation and review

SamSrinivas: I agree, add some urgency to the review

selfissued: wanted to run by WG; is September the right date?

tony: @@

vgb: We agreed in Berlin to aim for CfC on CR at TPAC
... encourage people to look at things now

tony: any concerns?

selfissued: I'll make those changes and send to WG list

tony: Comments to Mike by Friday, please, so we can post Tuesday after long weekend
... thanks, Mike
... vgb will send a tarball to SamW, who will publish
... and Mike will send blog post to SamW

Beyond FPWD

tony: extensions, vgb and JeffH had some comments

vgb: summarizing Berlin discussion: informal conversation saying spec should say "all extensions are optional" and point to registry for extensions
... e.g., IANA registry with open process for inclusion of extensions
... and also remove the extensions we have in the predefined extension section, move them to registry
... JeffH and I have been discussing; two pieces of text in the spec contradict one another
... one part saying extension can be requested by the caller, authenticator constructs
... another part says if you ahve extension you don't recognize, client should forward as-is
... but it might require processing by client
... so either we take out part saying clients will forward unrecognized
... or make no extensions require client-side processing

JeffH: some basic misunderstanding of registries
... you define extension in a spec, not in registry
... and then register a pointer in the registry
... to that spec
... so we can register things in an IANA registry while they sit in the WebAuthn spec

<gmandyam> Options exist within the W3C to create registries as well: see https://dvcs.w3.org/hg/html-media/raw-file/306bb395f94e/media-source/byte-stream-format-registry.html

selfissued: we can create a RFC to create an empty registry, leave extensions in the webauthn spec and register them with IANA
... so whether we have a registry or not is independent of whether extensions stay in spec
... I'm not convinced that removing extensions would help developers
... though we should be clear that spec-defined extensions have no special status, they're optional, on a par with other extension

tony: we need to do the registry-creation anyhow

alexei: I hear 2 things being discussed, technical issue of what clients should do with unrecognized extensions
... and second, where extensions are registered

vgb: 3 things: technical, where should ext defns live, should any extns be required?

SamSrinivas: I suggest first hard stuff, then registry, then any mandatory extensions

<JeffH> what do you mean by "mandatory" ? do you actually mean "pre-defined" ?

alexei: one thing we talked about in Berlin: requiring clients to pass through things they don't understand would be a tough self for clients

sellissued: protocol practice, if you don't understand something, you ignore it
... otherwise if you add an extension that won't be ignored, you break things

JeffH: we have multiple kinds of extensions

alexei: question on the table, should a UA that doesn't know what the extension is forward data to the authenticator?

selfissued: "ignore" means pass the data through
... and talking to an authenticator that doesn't understand does no harm

giri: I filed an issue to do a pre-defined extension, "opaque" to pass through to the authenticator

dirkbalfanz: in Berlin, we had a fairly short discussion on the subject
... because browser-makers seemed to agree that it's the user-agent's job to protect the user
... and if it doesn't knwo what an extn is doing, it can't do its job
... so "ignore" meant to us "drop on the floor"

giri: Qualcomm makes browsers, and we don't agree

<JeffH> per https://w3c.github.io/webauthn/#extensions -- extensions can operate at just the clientplatform level, and/or at authnr level

giri: there will be permissions the user should be responsible for

SamSrinivas: I thought we'd reached consensus that the "give me a unique ID" would be problematic, and that's possible with opaque

giri: I agree with Mike, but it's pretty clear we won't have consensus
... so I wanted a way to define an extension that carries data meant to be passed through without client processing
... there's not extn defined that way so far

alexei: giri, is your goal captured by taking extensions out and put them into an IANA registry?
... make all the extensions optional

giri: Jeff's point is valid, the registry itself doesn't specify the extensions
... the IANA route makes it lightweight after we've set up the registry
... e.g. some places where there's just pointer to a website

selfissued: we're conflating issues
... Can we define an extension, someplace, that lets data be passed thjrough?

vgb: I want to be clear what we're talking about

<JeffH> selfissued actually said "we /are/ conflating issues"

vgb: some people who make UAs feel that they can't be agents of the user unless they understand all extensions
... so we could say, in order for an extension to work, both client and authenticator must understand it.
... if you send an extension, in order to reach authenticator, you have to have at least one UA understand it
... Wouldn't that work for Qualcomm, if it worked in qualcomm browser?

<Zakim> weiler, you wanted to suggest some terminology

weiler: glad we're talking about "should we be passing data"
... terminology from BGP: "transitive"
... transitive attributes, get passed on whether or not you understand them; non-transitive don't

selfissued: in answer to vgb, if you don't require UAs to pass things through they don't understand, then a new extension never makes it through to an authenticators
... it gets dropped on the floor, so can't be acted on by authenticator

vgb: why si that a problem? if you have an upgraded UA, you have better results.

selfissued: protocols that enable extensions work in practice when they're not tampered with by default
... if having an extension requires everyone to act, then generally extension mechanism doesn't work and isn't used.

JeffH: clarification, does "dropping on the floor" = screwed with?

selfissued: yes, if it's dropped, the extension doesn't work

JeffH: part of the problem, the way the extension mechanism works, in order for transitive pass-thorugh
... the UA needs to know it to marshal data for authenticator
... we don't have standard framing
... to client platform, it's JSON; to authenticator, it's CBOR
... so the UA needs to know how to treat

<weiler> the value of transitive whatever seems greater when data is passing through many processing hops. It's not clear to me the this is such a case.

Rolf: that's not the only issue

JeffH: in order to pass data, client seems to need to "understnd" extn

vgb: 2 points
... in general, in protocols, it's perfectly fine to drop extensions

<weiler> here, we're talking about a relatively small number of steps in a client's stack. Not disparate servers scattered around the net.

vgb: secondly, it seems that requiring UAs to pass-through extns impoverishes the extn mechanism
... we have at least one where UA receives extension but passes nothing on
... authenticator selection mechanism, meant to trigger actions in UA, nothing sent to authenticator
... rich mechanism, the things sent to the authenticator are function of what's sent to the client
... we shouldn't require the fn always to be the identity fn

<JeffH> what vgb just said wrt client passing data to authnr is what I was trying to also clarify

vgb: to Giri's point, Qualcomm phone UAs can understand and pass on Qualcomm extensions
... and if it's useful, other clients will have incentive to understand that extension too
... today, RPs already do that, suggest you upgrade your browser
... I'd rather not impoverish the extn framework and create requirements by the back door
... i.e., create mandatory extensions "pass through"

JeffH: we could alter the API
... such that you can pass through data, without making any extension mandatory
... not sure it's a good idea, but it could be done

dirk: Giri, what do you think of vgb's point?
... do you still feel strongly that you want UAs to pass through?

giri: Jeff said we could change API, that would satisfy our use case
... as I said in email yesterday, I'd like something like FIDO UAF, client doesn't drop what it doesn't understand
... I don't think that gets consensus here
... so I'm looking for next best

dirkbalfanz: I thought you had your own browser that could understand the extension

giri: browser could understand it enough to know that it doesn't need to process the data
... parallel to clearkey exchange for EME
... but we don't need to adopt that mechanism
... there's precedent

dirkbalfanz: if you make the browser and you pass through the extensions, that's fine, right?

giri: we'll live with that
... I'm assuming the chrome side, all extensions are optional, so client can drop any as unsupported

JeffH: there's no mandatory-to-implement in the spec

dirkbalfanz: you're ok with "UAs drop extensions thye don't undersatnd"

giri: I'll live with, not happy

dirkbalfanz: Mike?

selfissued: I'm willing to go with the group; meta-point, think about how we make extensions usable
... could be that if UAs drop data they don't understand, new extns don't break the protocol flow

<gmandyam> I'm going to have to drop now. I'll check the minutes for any further discussion on this topic.

JeffH: given current design, whether or not there was breakage, in the eye of RP
... when it evaluates result from makeCredential or getAssertion
... if it doesn't get what it wants, then it knows something didnt' work
... though protocol operates

selfissued: if you use an extn no one understands, it should function same as if you'd used no extension

Rolf: challenge is that you need two entities who understand the extension, the client and the authenticator
... it's one thing to go to browsers, and another to go to authenticator
... substantial effect on the ecosystem

JeffH: Support what Rolf just said, good point

Rolf: it seems to slow things down, harder to get additional functionality in devices

dirkbalfanz: we don't want arbitrary functionality creep either
... extreme, arbitrary code execution

Rolf: yet we always said implementing authenticator left to authenticator vendors; now we're saying it requires browser cooperation too

alexei: client has a role to protect user's privacy, to enforce restrictions between RPs
... makes the job of the client harder if it doesn't understand semantics of API call
... if semantics are clear, then give flexibility to the authenticators

tony: want to get some agreement to move on
... we have options: defining no extensions in the spec
... defining extensions with semantics vgb and Jeff are advocating, optional

JeffH: whether or not extensions are defined in the spec is separate issue still

selfissued: the business property I've been advocating, that if you use a new extn, things work at least as well as if you'd use no extn, works under vgb's semantics
... that if the browser doesn't understand, it drops
... so long as spec is clear that all extns are option,

<Rolf> Sorry, had to drop-off.

selfissued: it provides documentation value to implementers to leave them there
... finally, I think we should est IANA registry. separately

vgb: it sounds as though we have broad agreement on IANA registry

JeffH: I can draft that

<selfissued> +1 to all extensions being optional

vgb: General agreement that all extns should be optional
... and it sounds like tentative agreement to leave pre-defined extns in the spec

JeffH: I don't understand why we'd want to pull pre-defined extensions out
... we could also invite Giri to draft a 6th predefined extension

<selfissued> I think leaving some extensions in the spec adds documentation value to implementers

alexei-goog: if we're making extensions optional, we might want a name better than pre-defined

JeffH: I have some proposed text to clarify

weiler: we could give developers the example of what to do with an unsupported extension
... opportunity to give an example of what happens if you don't understand the extension

JeffH: I have a bunch of clarifications, terminology in a pull request

vgb: I sent some comments last night
... suggest discussing on-thread

tony: let's wrap up
... I'll summarize on-list and maybe we can close extension piece

[adjourned]

s/doesnt'/doesn't/G

- DRAFT -

Web Authentication WG

25 May 2016

Attendees

Contents

FPWD

Beyond FPWD

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output