Page Comparison

1. Administration

5 participants - quorate

June minutes - Colin moved, John secondedDenny seconded

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

Guy: Govmts of Alberta and B.C. Have have separated credential from identity assurance. Federal Canda may go the same path. FICAM has identity assurance broken outis moving towards having a CSP separate from an attribute authority. Europe and UK having both in bind both and at the same LoA value. So it appears that Us US and Europe are marching different trust framework paths, as possible is Canada. NZ hard coded identity assurance into the valueswith 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 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. High A higher level of id 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 to a for a high assurance credential, thus would 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, with is a lower session assuranceand additionally leads to 'session assurance'. So there are potentially 3 dimensions, not just two.

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

Guy: A typical use case is the Multiple credential use case , some - some strong, some low – user may choose – session level is 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 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 is improved 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 in about this during the development of ISO 29115. ISO  ISO SC27 is currently creating identity proofing guidelinesstandard 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

JohnGuy: Alberta made a mapping about use 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.

(..) we should Colin: We could work on this inthe 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).