Outline of 1609.11 D1.0

1
June 2009

• Outline of 1609.11 D1.0

2
Definitions

• Application Application Core WIAL, where
• Application Core
• Main application-specific processing, but WAVE
  unaware
• WAVE Interface Application Layer (WIAL)
• Performs application-specific interfacing
• Interacts with Application Core via primitives
• Interacts with WAVE Stack via WME primitives and
  data plane per 1609.3
• Payment Service EPS Processing
• Provides services for Application Core or WIAL,
  depending on the system

3
Key Assumptions

• Applications (via their WIALs) handle WAVE
  communications
• EPS information is encapsulated in application
  messages

4
Structure of the standard (review)

• What does 1609.11 really need to do?
• Payment services identified so far require only a
  small amount of 1609 standardization (we can
  leverage other existing standards)
• Describe a basic set of common payment data
  services such as two or three data transfer
  profiles and two or three security profiles for
  data signing/authentication and encryption
• Describe a basic set of common management
  services such as service initialization and
  credentialing
• Two basic payment options identified at last
  standards meeting can be described via profiles
  in an Annex
• User and network preapproval (Preapproved
  scenario)
• Can be described as one or more payment profiles
  in an Annex
• User approval of at time of invoice and network
  approval at time of payment (Invoice scenario)
• Can be described as a payment profile in an Annex

5
Scope of 1609.11 (body)
6
Body of 1609.11 Payment Service Functions

• Both Payee and Payer Payment Service should
  support operations for encryption and decryption
  of octet sequences
• AES-128?
• 1609 security?
• TBD
• Payment functions will be described in annexes
• Will need different Payee and Payer Payment
  Service entities for Preapproved case versus
  Invoice case.

7
User and network preapproval (Preapproved
scenario)

• Pre-approved scenario
• User approves payments in advance of over-the-air
  transaction
• Payee generates receipt, may send account info to
  central payment entity offline or never

8
User approval at the time of payment, network
approval at the time of payment (Invoice
scenario)

• Invoice scenario
• End user approves invoice (e.g. via HMI, which is
  out of scope)
• Payee may send payment info to a central payment
  entity or entities (e.g. EPSNIS, which is out of
  scope)

9

• Annex A Profile for EPS for EFC using ISO
  14906/15628

10
Annex A Profile for EPS for EFC using ISO
14906/15628

• Special case of User and Network Preapproval
  scenario
• Governed by ISO Electronic Funds Collection (EFC)
  standards
• ISO 14906
• ISO 15628

11
Annex A Profile for EPS for EFC using ISO
14906/15628

• EPS processing in an EFC system may vary with
  each application
• Payment form may be different
• May communicate with central payment entity (real
  time or offline) or not
• Therefore, EPS/EFC functions are unique to each
  application

12
Scope of Annex A
13
Annex A Payment Service functions

• Payer Payment Service functions
• Retrieve payer account info, name, etc.
• Save receipt for this transaction
• Payee Payment Service function
• Create a receipt based on account info

14
Annex A WAVE Usage

• Payee WIAL submits WME-ProviderService.request
• PSID 1
• PSC BST (defined in ISO 14906)
• Other parameters as needed by Application
• Payer WIAL submits WME-UserService.request
• PSID 1
• UserRequestType Auto-access on service match
• ImmediateAccess true
• ExtendedAccess true
• Other parameters as needed by Application
• Data exchanges on SCH via unicast WSMP only

15
Example EFC Information Flow (part 1)
16
Example EFC Information Flow (part 2)
17
Example EFC Information Flow (part 3)
18
EFC Information Flow (part 4)
19
EFC Information Flow (part 5)
20

• Annex B Profile for Invoice system with data
  separation

21
Annex B Profile for invoice with data separation
scenario

• All applications need to use the same forms of
  payment, invoicing, communication with central
  payment entities, etc.
• Therefore, EPS functions must be in common among
  applications
• Payer and Payee Payment Services are separate
  entities with SAPs used by each applications WIAL

22
Annex B Principles of EPS in an Invoice with
data separation scenario

• Payment Services do no application-specific
  processing
• For example, a Payment Service entity may be
  implemented to serve many applications
• EPS information may only be originated or
  modified by Payment Services
• EPS information carried in an application message
  must be distinguishable from application
  information by an applications WIAL
• A WIAL is part of an application, so it doesnt
  know how to read EPS info (cant tell an invoice
  from a receipt), but
• A sending WIAL knows which octets contain EPS
  info versus application info based on where it
  came from (Payment Service versus Application
  Core respectively)
• A receiving WIAL can distinguish EPS info from
  application info based on position in the message
  body

23
Annex B EPS Information Elements (EPS IE)

• Same format as IEs in 802.11
• EPS IEs
• ID 0 Invoice
• ID 1 Payment
• ID 2 Receipt
• ID 3 - 255 Reserved
• Formats of ESP IEs are TBD

24
Annex B Encapsulation of EPS info in an
application message payload
25
Annex B WIAL handling of Application Message on
sending
26
Annex B WIAL handling of Application Message on
receipt
27
Annex B SAPs
28
Annex B Primitives
29
Annex B WAVE Usage

• Payee WIAL submits WME-ProviderService.request
• Parameters as needed by Application
• Payer WIAL submits WME-UserService.request
• UserRequestType Auto-access on service match
• ImmediateAccess true
• ExtendedAccess true
• Other parameters as needed by Application
• Data exchanges on SCH via unicast UDP only

30
Annex B Information Flow (part 1)
31
Annex B Information Flow (part 2)
32
Annex B Information Flow (part 3)
33
Next Steps

• Collect comments on D1.0
• Make revisions as needed
• Finalize security
• Finish Annex B define EPS IE formats