User Payment agent Task Force meeting -- 05 Dec 2014

<scribe> Scribe:steph

Joerg: important to discuss glossary

not sure what Evert think?

Joerg: we should be sure this is linked. We should define our terms, but ensure that we use all the same terms

<manu> +1 for not deviating from what the rest of the payments industry uses.

Wiki Status

Joerg: had a few pictures+text

https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force

joerg: i can explain and then give the floor to manu and David
... starting with https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#User_Payment_Agent
... didn't want to show a product, but what can be build. it is the straw man

proven architecture and use of protocols already working in user end

joerg: you have unified experience
... we believe that abstraction will have to play a role
... important question: how the agent will be called in a transaction by an application

we will have to work on

joerg: not sure it is the best architecture, but an architecture that works today

let's see if we can get something better?

<jheuer> Now!

Pat: question: where on the picture we have the concept of ?ledger

things like loyalty point, coupon etc

pat: currencies, account etc? where does that fit?

joerg: all the accounts should be represented by your identity
... same we could add status of a card, whether it is the default one, then individual entry per cart in the ledger

Pat: things that will gather things together

multiple items could contribute to a global wallet ledger

pat: representing aggregated value in the wallet?

joerg: the extension api is here for that there
... overarching functionalities. this is one of them, perhaps not usable for all of them

some items might be sum-up and represented

but up to the wallet provider

pat: one component in the black box could be the ledger

katie: example of a third party app working on the web?

joerg: example: loyalty application

Katie: api functionality: most of the thing happens over the web, but over nfc too?

joerg: yes both

katie: different kind of option and protocls is the transport layer change like nfc

joerg: hope to have everythign unified over time
... another example: banking applications

would not fit in a basic wallet, and bank would not want this

so offering a way to connect other applications

katie: ok, oepning room for branding etc. should be explained

David: premature to put in the hard way in the diag

but would be important to know what kind of info the wallet has access to

david: secure element have some. sometimes ppl put coupons in the SE

the SE is the place for the secret to protect the user, if not a secret, but encrypted in the device

SE should ahve pins and keys for that

cateogrie 1 data

category 2: coupons SE

category 3: database of the wallet

david: category 4: the wallet should be able to find out what data it stores that are not encrypted

joerg: database is one problem accross browser

<manu> http://caniuse.com/#feat=indexeddb

<manu> indexdb is supported in Firefox latest

acl manu

<Zakim> manu, you wanted to comment on layering / application layer / confusion.

manu: we are talking at the applicaiotn layer

in ip stack

then we diving down way way deep SE and nfc and then back way up etc

hard to follow the discussion

manu: W3C is not usually doing thing at the application layer
... so being clear where we are talking about just to clarify

will ease to follow the discussion

manu: i thnik the diag brings the elements we need to discuss but nto sure a newbie would understand it

joerg: +1

digram is not intended to be the result of the group, just a contribution

joerg: our job is to idnetify protocol, interface api etc needed

<dezell> Indexed database API - https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

manu: the application layer is something on top of the browser

katie: define that in the glossary

David: trying to address manu point to put something more abstraction

sounds like we go up and down, but it would help to find a common way to discuss of these

<jheuer> We have skipped the WebCrypto topic until Virginie has joined...

wendy: we should to not prevent to work at the application layer
... for ietf w3c work is all application layers :)
... we want to offer a layer that support other applications

joerg: +1
... how to make a good definition?

Manu: we need to discuss this more. I think it will emerge and we discuss

<Istvan> +1, agree with Wendy

manu: in the future we may have coupoin layer,; key layer etc. but not sure yet htis will evolve

Joerg: welcome Virginie
... now second diag, alternative stack

<manu> https://www.w3.org/Payments/IG/wiki/Payment_Agent_Task_Force#And_an_alternative_technology_stack.

joerg explains the stack

joerg: top ui, then metadata+html5
... below capabilities of the device where webcrypto fits
... in the middle the various elements. We need to keep legacy+proprietary

but we way also something else on the side

joerg: associating various elements that are needed in the payment, but may be useful alone too
... examples: emvco for nfc payment, but we can attach a new protocol where we transfer json object about coupons and coupons
... mix of legacy+web

part might be reusable in the web world

joerg: ultimate goal to reuse some of the elements

manu: vrey useful diag

acl manu

<Zakim> manu, you wanted to follow-up on "Web Payment Transaction Protocol" bracket.

manu right to allow proprietary system to use some of the standardized element like receipt

<jheuer> ack manu - great translation of jheuer's complex pics and explanations

manu: time should be in the picture (flow diagram)

we need another dimension, thus proposed the steps

manu: what is the technology stack at each step

manu thus we need not one tech stack, but depends on the step

<dezell> david: it's not so much a "technology stack" as it is a "technology array"

manu: i'm concerned with the diag

one picture is not good for everything

joerg: +1, need help

very hard to convey in a simple picture

no sure is time is right?

joerg: open for suggestion

<Zakim> dezell, you wanted to talk about manu's payment segments.

david: manu is extremly right to had a third dimension

not sure how, butthe time dimension is imho great.

i've adopted the steps

pretty good way for to adopt it

david: would help implementers to identify where they can act

<manu> +1 to david, exactly - technology array +1, an implementer may only want to implement something in one of the time slices +1

joerg: we shuold work work on things individually

david: yes, i may decide to plug various functionalities on wallet like replace the receipt management

<manu> +q virginie should talk.

Web Crypto

joerg: status on your side?

Virginie: web crypto api is being finalized implemented in major browser (google, apple, microsft mozilla)

you can generate a key sign something, and rely on the compatibility fo the browser implementing various algorythm

very flexible, any propriatety crypto algo

basics of mathemtics

this one is done

Virginie: now NFC. not involved in NFC api, mainly driven by intel

based tisen implementation

<virginie> http://www.w3.org/TR/nfc/

<jheuer> could crypto in webCrypto functionality be served from the SE?

virginie: some use case about nfc reading

but for card emulation or reader mode, not included in NFC api

virginie: for now web crypto does not tell where you crypto is done. not mandating SE

and no browser implementing this yet (using SE)

Joerg: any way to control whether it is done in the SE or now?

virginie: now in the current status no

but what may be in webcrypto next

clarifying if the cryptography is made is in the SE, is in the roadmap

on principle it will be in the next charter

so you made choose in your app if you want to use token-base storage

but can't say how this will be implemented

virginie: this is webcrypto in the SE
... byt now just about accessign SE, nothing done at W3C

webcrypto wg prefers that this will happen in a dedicated wg

because not all member are interested in accessing SE

so that's why, webcryptoi in SE in webcrypto

how to access info in SE should be something else

Virginie: me as gemalto I'm trying to find the excitement among other members to have a dedicated WG

joerg: deutsched telecom would be surely interested
... how to collaborate between groups? we may have new requirements in the new group and the future web crypto

<Ryladog> new Working Group under which domain? Sorry I missed that

virginie: globalplatform gather ppl interested in SE access from the Web

and w3c has a liaison

we need to have browsers on board

Manu: how fido/U2F fits into all of this? plan to coordinate? merging with web crypto?

how this is coordinating

virginie: W3C and fido are working on ensuring coordinatino

U2F 1.0 will go public soon, and they may ask to been integrated in W3C

second point, authentication service

not part of web cyrpto participant interest

so this would be part perhaps of the new WG

not sure yet

<manu> great answer, thanks Virginie! :)

Fido objective very clear: they want their api accessing fido client be part of W3C

joerg: we should look wether if fido can be used by payment

virginie: fido core objective is payment, so shuold monitor that

<jheuer> Who can join to work on the 'Tech Array?'

PAt: happy to help

will send something

<manu> Manu will try and propose something wrt. Tech Array picture.

steph: next meeting?

<virginie> ok for me

joerg: next call on the 19

<virginie> ok

adjourned

<manu> thanks Joerg!

- DRAFT -

User Payment agent Task Force meeting
05 Dec 2014

Attendees

Contents

Wiki Status

Web Crypto

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

User Payment agent Task Force meeting 05 Dec 2014

Attendees

Contents

Wiki Status

Web Crypto

Summary of Action Items

Scribe.perl diagnostic output

User Payment agent Task Force meeting
05 Dec 2014