<scribe> scribe: hhalpin

hhalpin: Any blocking issues outside of Vijay's for F2F?

rbarnes: And it seems like today and f2f, we should be able to get through the last final issues

hhalpin: We want all editors and chairs at the meeting

F2F

Will check in with folks in terms of registration

Walk though issues (Vijay's clean-up)

vgb: I'd like to walk through the list of issues
... that I brought up in my email
... and at least get nominal issue on 3 of the issues
... first issue is the abstraction layer for attestation
... we did some refactoring of the spec
... to separate out authenticator model of the Web API
... I'll send out a proposal for attestation core
... I think it would simplify things to make a more abstract interface

jeffH: Its nominally fine with me

vgb: I'll sketch it out in the pull request and send it out

Hubert: Put the Android Attestation in a separate doc?

<Hubert-PayPal> that was Hubert asking :)

vgb: The idea is not to change what is in currenct document
... its interesting but not fundamental to the Web API itself
... so if you are writing backend, you need to know the authenticator model
... so there's stuff in the Web API section that should go to the authenticator model
... I'm just moving content between sections, same content

JeffH: You are moving 3.9 and 3.10 to Section 4

vgb: The current spec has Header, Core, and Signature
... inside the core part there is a type and a version
... the initial thought is to pull out type and version
... everything else is as defined by type in authenticator model

rbarnes: Makes sense

JeffH: Worth a try

Sounds like rough consensus to me

vgb: Slight tweaking of structure, but make things simpler cognitively
... Issue 2)
... Issue 58

s/58/58

scribe: There are two boundaries
... if you give somebody a signature that is generated for an unexpected orgin, its thrown away
... the other part is to be able to ask for signature and get one, reveals access of that credential
... that's a privacy boundary
... this is where eTLD+1 comes in
... if you aren't in the same eTLD+1
... then we can't even ask for the assertion
... we just act like its not there
... its not clear in the spec right now
... I'd like to write it up in the spec
... people do not have seem to understodd these points when we talk about it

JeffH: Its' also security
... we don't want anyone to generate assertions with an arbitrary private key

vgb: What is we allowed ANYONE to generate assertions with ANY key
... regardless, SOP would reject signature

rbarnes: However, that's dependent on relying party doing the right thing

JeffH: So it's both privacy and security

vgb: There's a section on how you should validate an assertion

rbarnes: Might be worthwhile in Security Considerations or Introdution
... just have a discussin of this origin issue

vgb: I'll try out various things and see what works

rbarnes: Do folks here agree on two-level taxonomy?

JeffH: Its nominally how things work, folks have to read between lines

<Rolf> One comment: we relying once more on the authenticator to control the to-be-signed object. This precludes a certain class of implementations. At this time the traditional KeyStores/Chains do NOT allow the secure platform to control the to-besigned object.

vgb: Third issue - we rely on DOMString
... lots of base64 encoding
... it complicates the protocol to actual authenticator
... due to things like Bluetooth LE
... low rate links
... you have to translate back and forth, and sending potentially bloated base64 over a link
... alex noted why arent these all DOMStrings?
... so I noted that these things were essentially Array data
... we just happen to base64 them
... if you were a script author
... so if you send to a server, you'd have to TextEncoder

rbarnes: I want to keep octet strings as octet strings
... we want to keep sync'ed the thing that is signed and the thing that is presented to call Javascript
... in U2F spec that some things are signed as base64 as specific octets

<Rolf> +1

rbarnes: but for these things that are signed, then we should keep it as base64

vgb: I'll do this as a sanity check
... so everything that is signed is given back the same way
... note there's slight ambiguity in base64
... so we don't want to have peple to do translatin to validate signature
... Some things are octet strings are specified as strings in credential management spec
... there is not a way to do both things

jcj_moz: After more review
... I'm not sure we need to align with the credential management spec
... that this is sufficiently different
... where it makes sense to us to say 'this is binary'
... even if it messes up alignment

rbarnes: Is this a blocker for FPWD

no

rbarnes: Let's move this issue to next milestone

vgb: I'll focus on this batch of fixes first, there will be another

rbarnes: When should we do review?

vgb: Will send these changes out
... this week

rbarnes: Volunteers to review these changes?

JeffH: Sure, I'll volunteer

jcj_moz: I'll review these changes

rbarnes: With this, we've gone through FPWD issues

AOB

[discussion over if we should go for call next week]

Let's just have one to help with Agenda for F2F, possible controversy for call

rbarnes: I'll sesnd an agenda out re F2F based on reviews

Meeting Adjourned

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/dirk/Hubert/
FAILED: s/58/58/
Succeeded: s/56/58/
Found Scribe: hhalpin
Inferring ScribeNick: hhalpin
Present: felipe_bbg Sam Srinivas

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 27 Apr 2016
Guessing minutes URL: http://www.w3.org/2016/04/27-webauthn-minutes.html
People with action items: