hi all, call is starting :)

<acouvert> hello everyone

<phofmanntsy> Peter Hofmann

Welcome and introduction

CG objective reminder

<wseltzer> virginie: goal of this CG is to demonstrate the value of using hardware-provided secure services for the Web

<wseltzer> ... aim to be quick, to spark conversations with user-agent-implementers

<wseltzer> ... in order to bring proposal to W3C

<wseltzer> ... timeline, a few months

<wseltzer> virginie: documentation and prototyping/demonstration

Review of Morpho’s contribution (see https://rawgit.com/w3c/websec/gh-pages/hbss.html)

<wseltzer> virginie: Sebastien sent draft to list

<wseltzer> Sebastien's draft Hardware Based Secure Services Report

The draft is here : https://rawgit.com/w3c/websec/gh-pages/hbss.html

<wseltzer> Sebastien: review the high-level table of contents

<wseltzer> ... this is a draft to kick off conversation

<wseltzer> ... Terminology; Problem Statement; Use Cases

<wseltzer> ... Problem statment: key access, management, user verification

<wseltzer> ... API design

<wseltzer> ... at high-level, key usage, and secure credential storage and management.

<wseltzer> ... Architectures and security requirements

<wseltzer> virginie: thanks Sebastien! I sent some comments

<wseltzer> ... use cases are important, to convince implementers there's value

<wseltzer> ... questions?

<wseltzer> virginie: are we going to describe scenarios where smartcard or trusted UI is used?

<wseltzer> ... e.g. citizen identity, high-level?

<wseltzer> ... or more detailed to secure transaction confirmation, key management?

<wseltzer> Sebastien: possibly both

<wseltzer> ... e.g., Estonian citizen who wants to sign documents, needs to prove identity, make signature

<wseltzer> ... then propose use transaction confirmation as alternative

<wseltzer> ... to achieve functional goal

<wseltzer> Sebastien: if we want to add transportation, e-health, people should give input on the use cases

<wseltzer> virginie: I'll ping Deutsche Telekom on transportation

<wseltzer> ... remove topics on which there's no contribution (for the moment)

<wseltzer> virginie: a short paragraph on how secure transaction confirmation and secure credential storage support those use cases

<wseltzer> ... then move on to API

<wseltzer> virginie: did we say we'd cover device authentication?

<wseltzer> Sebastien: Visa requested for online payments

<wseltzer> ... instead of explicit end-user authentication

<wseltzer> virginie: I was expecting an API for transaction confirmation; an API for using and storing keys

<wseltzer> Sebastien: so for signature, do we say "rely on webcrypto, with additional support"?

<wseltzer> opoto: we can reuse webcrypto with additional notion of a crypto provider

<wseltzer> brunoj: hardware backing on webcrypto would answer 80-90% of use cases

<wseltzer> ... is that an acceptable option?

<wseltzer> ... that would be valuable

<wseltzer> virginie: that proposal could be made to W3C, either to extend WebCrypto or in a new WG

<wseltzer> rigo: issue of unscoped token

<rigo> rigo: We shouldn't preclude too many things. CGs are made to explore. We will find new issues running down the generic use cases, find that imagined issues aren't as dramatic and perhaps add needed futures (scope of tokens)

<rigo> sebastion: scope could be within the key itself to avoid relying on browser implementation

<wseltzer> https://www.w3.org/TR/webauthn/

in web authentication : scoped is aused here : https://w3c.github.io/webauthn/#iface-credentialInfo

<Sebastien> sebastien: proposition to rely upon existing keys with scoping enforced by browsers

<brunoj> https://www.w3.org/TR/2016/WD-webauthn-20160531/#scopedcredentialinfo ?

<wseltzer> [[ Scoped credentials are always scoped to a single WebAuthn Relying Party. ]]

<wseltzer> https://w3c.github.io/webauthn/#use-cases

<wseltzer> virginie: work to propose amendment to webcrypto that supports storing a scoped key in hardware

<scribe> scribenick : virginie

bruno: how do you select the key in the TEE or Secure Element ? how will be managed the choice ? any naming rule ?

sebastien: do you mean pre-filterning the type of SE that may be used ?

bruno: yes
... and usually there is only one credential

sebastien: filtering is also about being able to discover what is inside the providers
... proposal is not to allow to select by the user, it is more about the authority that will help making choice

bruno: thinking about the already enrolled credentials in the web part
... discovering can be risky, but the discovery could be made by OS and/or by browser
... in current implem, you can select at browser level the type of video/camero you want to use

sebastien: yes, and video is not a sensitive value, whereas, secure element and sensitive application may be more complex to handle
... discovering by a simple service request, has to be protected

rigo: an API must not deal with User Interface, the web app will handle it
... about the naming, ig you find id in the web, you can always turn them into URIs, so, we should be carefull allowing any web app scanning key presence without user consent

option 1 : the user select the key, option 2 : the user pre-defines a choice that the borwser owns, option 3 : the certification authority is the main trigger to elect the right key

it is discussed that the borwser first filter based on CA, and at the end of the day, the user will have to be aware that this is happening

<rigo> key discovery is certainly a fingerprinting issue

sebastien: about the digital sinature, we will have to sign the document without displaying it to the user
... thus, it will be the choice of the service provider to accept the signature with some non-repudiation data
... there should have some nested operation, such as signing document, then signing the message, and checking both are valid

rigo: why document can not be presented in trusted UI

sebastien: because Tusted UI has some capabilities which are limited

sébastien : thus we have to provide a complex document signature, but we have to add another step for the non-repudiation

sébastien : we need to provide something that is understood by the end user

rigo: feel there is a limitation in stating that a large or complex document can not be used in a Trusted UI, and this is not suitable to the web spirit

sebastien: but the garantee that the user confirm the content has to take into account the accessibility, the capability of the user to actually check every bit of the docu, including the images

rigo: we should define an intermediate levl where we can garantee that there is a 'some' security in the digital signature

to rigo, please check I correclty reported your statement :)

sébastien : the trusted Ui should not rely on the browser, but on the system underlying (TEE or operating system, or whatever or a middleware is able to provide some secure display)

virginie: lets comment the chapter 5

sébastien : this is description of the different elements that will be involved into that solution

sébastien : there are some parts touching the browser, parts touching the operating system, each of them having their caracteristics (Windows and android hving different security models)

sébastien : it is a decsription of the security requirements

<brunoj> ok for me

<brunoj> +1

<Sebastien> +1

<rigo> -1 very difficult that week

+1

https://www.w3.org/community/hb-secure-services/participants

<wseltzer> virginie: next meeting June 15

<wseltzer> [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/cerfull/carefull/
Succeeded: s/whatever/whatever or a middleware/
Found ScribeNick: virginie
Inferring Scribes: virginie
Default Present: wseltzer, virginie, acouvert, phofmanntsy, rigo, colin, bruno, Sebastien, opotonnier, Ketan, mzwolinski, Laurent
Present: wseltzer virginie acouvert phofmanntsy rigo colin bruno Sebastien opotonnier Ketan mzwolinski Laurent opoto

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

Agenda: https://lists.w3.org/Archives/Public/public-hb-secure-services/2016May/0011.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 01 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/01-hb-secure-services-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.