Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

Mai 05: June 01, 2015

1. Attendees

  • Denny Prvu

    John Spicer

    Ken DaggAngela Rey

    Colin Wallis

    Rainer Hörbe (taking notespresenting)

    Thomas Gundel

 

2. Approve minutes of previous meeting

- no quorum

 Carried over

Discussion Items

3. Work item

...

: Code of

...

Conduct for entities (e.g. govt) acting as relying parties"

- no new input

4. Q&A session Canada Cyber-Authentication Architecture

Ken provides a brief overview of the topic. (Disclaimer: Ken providing his private view as an ex-employee of the CA government).

Govmnt departments in their role as relying parties are responsible for getting the identity assurance they require. Thy are following a standard published by the CA government to figure out the LoA they need for each service they have on-line.

CA govmnt implemented Logon service, offering either a govmnt or a financial institution credential. Financial institutions are connected via a broker. The broker is CSP to department on one side and RP to financial institutions on the other side. The user identifier is the MBUN (meaningless but unique number) and a yes/no authentication decision.

 

This design is referred to as „triple blind“, because no party knows all parts: The department knows who is asking for, broker knows the department, but no user attributes. This is anonymous. Identity information is collected and validated via another channel by the RP.

 

Clarification: This is partial anonymous – with a good reason like a court order and some effort the identity at the CSP could be recovered.

 

The government is working on a new service for validation and verification of identity data. If will allow users to choose where their identity data will come from. It will in most cases not be the same service that is providing the logon. There are still issues. (Who are authoritative parties for the data, and are the registries accessible – these are pretty old systems)

 

Liability: If any of the players are performing according to LoA2 the not liable. Ultimately the RP is liable, unless they can prove, that any other party dod not perfor as specified.

 

Usage pattern: government cred. 10:1 EI claims. Factors: RP’ screen design: government 1st initially; not all banks participate; If you have one already from previous system.

 

Rainer will provide slides for a talk to be given on May 21. at the IEEE workshop on privacy engineering at the next meeting. The talk covers a comparison of several privacy-enhancing approaches to federation IDM, including the Canadian approach.

 

5. Reports from recent conferences

Rainer reported from the MAPPING Round Table in Geneva, March 16./17., where there are intersections in the topics of internet governance, surveillance, privacy enhancing architectures in internet identities. Link:

http://www.mappingtheinternet.eu

 

6. AOB

none.

 

Next Meeting: June 1., 2015Care needed for RP to look after attributes in privacy respecting way.

eIDAS has no provision for this.

Federations should use metadata, technical trust in compliance and certification.

'Context should be an added criteria.

Example use cases: RP does eTenders for other RPs ..e.g. US Fed Gov has active website where vendors register (SAM.gov?)..that does not provide identity services. External user would arrive via FICAM , in future also Connect.gov. Individuals use separate access from a different federal database... 'if you using a PIV Card, certain rules apply for the RP.

 

ACTION: Check with Kantara IAWG if PIV Card in scope for IAF.

4. Rainer's presentation on 'Privacy by Design in Federated Identity Management'... previously submitted to IEEE Privacy and Security conference May 21st 2015.

Link to slide notes is here: Image Added    eGov - Dateilisten                     

Note to self to find link for slides

ACTION: Rainer will supply speaking notes and references to help explain slides.

Slide 5: Look outside FIM...

Slide 6: Project co-authored by Rainer

Slide 8: ISO 29100 and PbD rules and principles..

Slide 9: Linking of delta between different privacy domains. Peering servcice without being able to link up ...limited linking capability

Slide11: Designed new 'blind proxy' and uses centarlised login (like DK's Nemlogin, AT's, NZ's. Summary: Late binding like Fed Canada's CATS spec of FIDO U2F. 6 alternatives with controls that trust the use of the metadata.

Slide 17: Temporary linking, on edirection (pairwise identifiers).

Slide 18/19: Constrained Linking..limited time (1hour say). via the proxy.

Slide20: Biullet 2 is ABC4Trust

Slide 21: PE FIM = blind Proxy

 

Comment: Needing plain language version to get better adoption. by re-stating architecture into common language that the user understands.

Comment: Highlight difference sin privacy requirements.. invdividual vs employee.

5. Reports from recent conferences

Carried over to next meeting

6. AOB

Kantara Virtual plenary coming up late June. Angela suggest a presentaion from Connect.gov