2014-07-07 eGov Meeting Minutes

1. Administration

5 participants - quorate

June minutes - Colin moved, Denny seconded

2. Discussion: separate LoAs for identity proofing and credentials?

Guy: Govmts of Alberta and B.C. have separated credential from identity assurance. Federal Canda may go the same path. FICAM is moving towards having a CSP separate from an attribute authority. Europe and UK bind both and at the same LoA value. So it appears that US and Europe are marching different trust framework paths, with Canada as a mixtur eof the two dependent on Province or Fed. NZ binds identity assurance into the assertion the RP receives from the CSP, but can have additional (potentially different) values from Identity Attribute Authorities. So it will be interesting to see how these frameworks evolve on the policy and protocol levels, and if they will ever map effectively.

Rainer: What are the requirements for relying parties to separate cred. and id assurance?

Guy: LoA of identites and credentials are not aligned. Alberta is also considering to use multiple credentials of different strength, e.g. from 3^rd parties.

John: When identities are shared between governments, they might want to know the different types of LoA.

Matt: For the UK it is all about the (RP) service consuming knowledge and confidence about the user for transactions. A higher level of credential assurance does not provide more trust if the level of id is lower. On the other side, if id assurance is low, there is no need to pay for a high assurance credential, and also would not be proportionate.

Guy: A use case that we have to deal with is a low id assurance and a high cred assurance, and additionally leads to 'session assurance'. So there are potentially 3 dimensions, not just two.

Matt: .. The level of proofing is the more expensive part.

Guy: A typical use case is the Multiple credential use case - some strong, some low – user may choose – session level assurance becomes the lowest of the two.

Colin: History in US is based on NIST 800-63: It was designed for enterprise-type authnentication, now it is used as baseline for G2C space which is not what itw as designed for.

Matt: In the UK we are struggeling with finding a use case where you need a strong credential but low proofing.

Rainer: With some use cases where the service does not link to pre-existing PII, there might be a benefit to have a stronger credential, but it is up to the user to decide. There might be no need to enforce it by the service.

John: Proofing will improve over the course of the next couple of years, that is why the values should be separated.

Rainer: For the long term it might make sense to put the additional assurance values into some attributes, and use the AuthenticationContext for the combined value.

..

Colin: There was a discussion about this during the development of ISO 29115. ISO SC27 is currently creating identity proofing standard for people, organizations, devices and software (ISO 29003) because identity proofing processes (as opposed to the LoA as a concept and a result of the process) was considered out of scope.

AI: Colin to extract salient pieces from the ISO document and share it in the WG.

Matt, John emphasize the need to agree on terminology.

Rainer: We had a discussion on the scope of LoA a couple of years ago. There is a slide in:

http://kantarainitiative.org/confluence/display/TFMMWG/Enhanced+LoA

Guy: Alberta made a mapping regarding LoA treatment in different countries. Will ask to make this available to the group. Canada has to come up with names and values and associanted use case.

Rainer: 29115 defines the scope of LoA .. includes both IPV and authentication. I think that min(IPV, credential) is a common semantic for SAML authentication context. But this needs to be discussed. Anyway, the scope in 29115 is clearly described: includes IPV and authN, but not anything after the authentication event, like session protection, e.g. holder of key-type models.

Colin: Formally, the scope of SAML authnContext is defined out of band.

Colin: We could work on this in the group and propose a solution in eGov profile or saml2int; could then propose this to this OASIS SSTC.

Matt: will try to contribute something abount session assurance (may be a bit embryonic).