<weiler> present=

<weiler> scribenick: vgb

nadalin: Could discuss open PRs. Jeff and Alexei not here yet, so maybe skip for now.
... did anyone review?

vgb: I did - look at Jeff's change removing publicKey from ScopedCredentialInfo if you can.

Rolf: is there supposed to be something in the vgb-u2f-attestation branch?

vgb: i'm fighting my git client, will push something up.

alexei_goog: few comments need to be addressed on the PRs
... such as the question around what if rpId and U2F appId extension are inconsistently specified.
... haven't looked at Jeff's PRs yet, will do right now.

nadalin: some PRs, 16 open issues on WD-03 milestone

gmandyam: question on PRs
... comment on one of the PRs said attestation info wasn't present in getAssertion response
... so no way to include dynamic "attestation" info such as health state in assertions?

vgb: can do it as an extension similar to UVI or UVM
... attestation info itself is only generated at makeCredential time.

gmandyam: look at platform attestation such as SafetyNet. so if you wanted to get the API safety information again at getAssertion time, you'd want to define a SafetyNet extension. that's fine if that's what the spec says.

vgb: yes

alexei_goog: trying to understand where the public key will come from now that it is removed from ScopedCredentialInfo

Rolf: it was always the case that the attestation included it, because it has to be signed over.

there is an echo echo echo

alexei_goog: ScopedCredentialInfo has publicKey now, is the proposal for the pub key to come from authenticatorData?

gmandyam: yes
... section 5.3.3

<JeffH> the credential public key is (and always has been) coveyed in authenticatorData."

<JeffH> attestation data"

<JeffH> see issue #94

alexei_goog: still not convinced

<JeffH> scopedCredInfo.publicKey is not utilized anywhere in the spec (in master branch)

vgb: 5.3.3 will be tweaked for u2f, but every format will have the public key in there

gmandyam: so this is a requirement on attestation formats now

vgb: yes, this will be in my u2f change

alexei_goog: and presumably the format of the key will be specified

vgb: yes, for each format

alexei_goog: about the AAGUID in there - one purpose of this is to look up metadata service
... ideally should be a canonical way to go from AAID (UAF) to AAGUID

<JeffH> simplly regard AAID as a byte string ?

vgb: could just generate random number and check against MDS if you really want to make sure?

alexei_goog: AAID also contained a vendor ID which worked well. can we have a mapping from there to AAGUID?

<apowers> AAID is in the format VVVV#DDDD

<JeffH> simplly regard AAID as a byte string ?

vgb: could we just say AAGUID = SHA256(AAID) for such authenticators?

<apowers> where VVVV is the hex encoding of the Vendor ID and DDDD is four hex bytes for the Device ID

<JeffH> could do that too

<apowers> so technically AAID is 4 bytes

alexei_goog: could do that, but since AAID is so small maybe more potential for collisions?

<JeffH> thety are backed by a registry

<Zakim> weiler, you wanted to tell Jfontana he's been muted. and to announce the PAG, before the top of the hour

<apowers> vgb: it follows the same model as other CE standards -- assigning a namespace to a vendor and then letting them figure out how to assign the numbers in their name space

alexei_goog: still seems icky to me, but meh
... seems like no strong opinions?

apowers: nice thing about AAID is that it includes a vendor ID so you can ban a vendor completely

alexei_goog: but you could do the same by looking up vendor in MDS based on AAGUID?

apowers: maybe, not sure.

alexei_goog: but MDS may want to maintain one index not three, so may be good to have a deterministic AAID -> AAGUID mapping

<JeffH> i would do most simply conversion of aaid to aaguild and add text to aaguid that impleentors should only generate aaguids that are some fixed length >> 9 bytes

alexei_goog: reason for asking: when a BT device shows up we want to give user instructions on how to pair, so we'd like to look that up (maybe in MDS) based on PNPID
... will make a PR containing some arbitrary-but-logical proposal

<JeffH> vgb: sounds good

Rolf: would like to think through the implications - potential collisions between PNPIDs and USB IDs, and so on

<JeffH> yeah -= so perhaps send such an analysis to the list?

nadalin: putting alexei_goog on the spot about issue #88 :)

alexei_goog: this was mostly a note to self, haven't done anything more

nadalin: #102?

vgb: have been meaning to do that one

nadalin: #123, not sure if we came to a resolution?

<JeffH> i will work on #123 today/tomorow

nadalin: WebCrypto or JWS?

<JeffH> it is assigned to me

vgb: why not JWS? WebCrypto is only advantageous if you allow the full dictionary so it can be more expressive.

Rolf: haven't had cycles to work on it

JeffH: (on IRC) will work today / tomorrow

<JeffH> vgb: thx

gmandyam: would prefer to follow W3C precedent by using WebCrypto (which is W3C) instead of JWS (which is IETF)

<JeffH> we need to figure out whether the data obj in question are JWS or are WebCrypto and then use the correct term.

nadalin: let's try and get these closed as soon as we can so we can do a WD-03 and later a CR

<JeffH> pls review current PRs

nadalin: try and make some progress

vgb: has more time after 21st

Rolf: has more time after 28th

<JeffH> jeffh: has time this week & next

nadalin: people still believe that 27th is doable for WD-03?

Rolf: maybe need 2 weeks more

nadalin: will push it out another week, and CR correspondingly
... AOB?

<Zakim> weiler, you wanted to announce the PAG, before the top of the hour

nadalin: a PAG has been formed. some of you may be contacted. that is all.
... see you next week

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: vgb
Inferring Scribes: vgb

WARNING: No "Topic:" lines found.

Default Present: weiler, gmandyam, rbarnes, nadalin, apowers, Rolf, vgb, alexei-goog, angelo, (on, irc, only), jfontana, Ketan
Present: weiler gmandyam rbarnes nadalin apowers Rolf vgb alexei-goog angelo (on irc only) jfontana Ketan
Regrets: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Oct/0056.html
Found Date: 19 Oct 2016
Guessing minutes URL: http://www.w3.org/2016/10/19-webauthn-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report