SV_MEETING_TITLE -- 16 Jun 2016

<Sebastien> wseltzer: yes

<virginie> hello all, details of the call can be found here https://lists.w3.org/Archives/Public/public-hb-secure-services/2016Jun/0008.html

Trying to dial in, just getting steady tone

<chaals> (says it can't connect me to the call, after getting my name and trying…)

<virginie> @chaals try this number local number from here : https://lync.gemalto.com/dialin

<virginie> @marko, where do you call from ?

I'm in now.

<chaals> [By the way, I'm trying to make a link to the work of this group, and wondering where I should link to…]

<wseltzer> chaals, https://rawgit.com/w3c/websec/gh-pages/hbss.html#dfn-method-confirm is the document Sebastien is talking about

Sebastian: what has changed in document - a new introduction. Section 4.1.3.1 confirmation method.

<virginie> to chaals, we are working on the mailing list https://lists.w3.org/Archives/Public/public-hb-secure-services/, and on the github area https://github.com/w3c/websec

<wseltzer> chaals, here's the group's homepage: https://www.w3.org/community/hb-secure-services/

<virginie> [I think that we should publish on a regular basis some post on the CG home page to give a clear view of the group activities and progress, thanks chaals]

<virginie> mark : will we have to use TEE for trusted UI

<virginie> sebastien : all implementations are possible and we will have to add this into the document

<virginie> peter : will it be a normative part ?

<virginie> sebastien : it will be informal, as it will be implementation dependant

Virginie: reminder that we are not producing a standard, we are a non-normative group

<virginie> peter : there will be different security and trust level depending into the context (with or without TEE, for example)

<virginie> virginie : we may use a list-description of the context for executing the secure transaction confirmation

<virginie> virginie : we might have to list technologies involved and possible scenarios (is there a TEE, yes, no, is there a tamper resistance storage of key, yes, no, ....)

<virginie> peter : yes, that would be great for the srevice provider to make decision when/if to run the services

sebastien: privacy issues about keys managed in smartphone

<virginie> sebasteine : we will have to be careful with the privacy, by dsclosing too much things to the web app

<virginie> sebastien : this is why we decided to have the user involved into the choice of the credential to use for the confirmation

<virginie> sebastien : we will have to have the user and the service provider involved in the choice

<virginie> sebastien : we mentionned in previous discussion that the key will be associated with a given service provider, so the choice might be quite easy

<virginie> sebastien : the role of the certificate authority can also be usefull to make a choise : the Service provider may have its own list of acceted CA

need increased explanation in section 5.1 and 5.2, plus add notion of attestation

attestation = information related to context of storage and execution

attestation notion can be reused for transaction confirmation and secure credential storage

Virginie: do we consider that attestation should be signed by someone, or up to browser to ensure that it cannot be modified?

Should not be replayable - needs to be ensured by some cryptographic signature

<virginie> virginie : in the field today, there is no such as signed attestation

<wseltzer> [note there's an attestation in the webauthn: Styling with Markdown is supported

<wseltzer> Comment Close issue

May be added later on, when attestation is available on trusted UI component; FIDO already has concept of attestation

<wseltzer> s/Styling with Markdown is supported/https://w3c.github.io/webauthn//

<wseltzer> https://w3c.github.io/webauthn/

<wseltzer> s/ Comment Close issue

<virginie> sebastien : the attestation will collect the information aboutvthe Tusted Ui and the secure storage capabilities

<wseltzer> https://w3c.github.io/webauthn/#attestation

<virginie> virginie : then what do we do ?

<virginie> sebastein : we may just consider that the device manages attestation transarently at first usage

V: If a user agent implements the API, and wants to integrate attestation first, how can we do that?

S: because there is no attestation, we cannot request to support attestation. So first verstion would be without attestation.

Second version: as a result of transaction confirmation, the confirmation/cryptographic element + attestation to give additional information to server about the environment

V: What would be this piece of information? S: provided by the browser V: How would the browser get this information?

S: for smart card, it would be something new, so would not be there at the first day. Expect that TEE would provide description of its environment. Way to prove to service provider that it has been certified.

V: would like to measure work in explaining why we need attestation.

<virginie> sebastien : this would have to be managed at key issuance/creation

S: for transaction confirmation, too complex for service providers to implement individually. Manage at key issuance. Certificate authority will issue key only if managed by TEE.

<virginie> sebastien : thus the service provider would not have to manage this kind of complexity

V: suggests Sebastien writes requirement for attestation into document.

<Sebastien> https://rawgit.com/w3c/websec/gh-pages/hb-secure-services/SafranIdentitySecurity_Authorization-model-for-Javascript-usage-of-hardware-based-keys.pdf

<scribe> Agenda: scoped credentials

<virginie> mark : are you proposing that, in the rowser approach, that the same key is used across different services ?

<virginie> mark : how do you garantee the pricavy ?

<virginie> sabstien : it will be under the exclusive control of the user

<virginie> virginie : whihc solution do you prefer ?

<virginie> bruno : prefers the second approach with ADSL

<virginie> mark : suggests that we have a pro/con analysis

<virginie> sebastien : yes, I can provide that

<virginie> bruno : in the second approach the user is participating to the authorization od domains

<virginie> sebastien : the second approach needs work on the UA side, as it is a complete new feature

<virginie> sebastien : but it fulfills the expectation of the user controling all the credential and taking into account the service provider policy

Virginie: priorities for community group: secure credential storage needs to be written, scoped credentials would be priority 3 behind secure credentials + transaction confirmation
... may ask CG members for more input on the scoped credentials proposal
... want CG to be able to show to browser vendors what we can do, so will need some implementations

Ideas to improve webcrypto API to include secure storage suggestion

Virginie: how can we present prototypes? Would Sebastien have a demo in September?

Sebastian: has modified middleware available already; need to link to transaction confirmation API

V: would it be available for a mobile?

Sebastian: would be a PC-based demo. Agrees definitely need to do something on mobile

V: more willing to work on mobile side

S: mostly done on Chrome, or Firefox. V: Gemalto to work on Firefox

<scribe> Agenda: should we meet during TPAC? W3C meeting in September in Portugal.

<virginie> virginie : will you be at TPAC ?

<virginie> +1

Mark: not in Lisbon, not sure whether Colin would attend

<phofmanntsy> +1

Virginie: ask w3c about possibility to invite non-w3c members.

V: Wednesday at W3C is open to absolutely anyone,brainstorming day

Virginie: Sebastian's document still needs to have some use cases. Ping Brian for bank-related services.

V: Could Peter have a look at the different use-cases?

<Sebastien> +1

-1 for Tues 28th.

Will check with Paul/Colin for 28th.

Will have next meeting on Tuesday 28th at 1400 UTC

quit

- DRAFT -

SV_MEETING_TITLE

16 Jun 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output