[Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)
Tom Jones
thomasclinganjones at gmail.com
Thu Feb 14 15:00:56 UTC 2019
I cannot see how the User info endpoint can be used to separate authn from
attribute proof. As i read the spec the User info endpoint must be a part
of the OP. I believe that we must find a way to separate the User info
endpoint from the OP completely to solve the problem.
We have a use case funded by NIST and supported by AAMVA in the US. There
the AAMVA would validate claims that were presented. In other words, the RP
(client) would collect the data (claims) from the user and send them to
AAMVA for validation. The data would NOT be supplied by AAMVA. This
involves the user more directly in a granular processes of granting consent.
Peace ..tom
On Thu, Feb 14, 2019 at 6:26 AM Jeff LOMBARDO <jeff.lombardo at gmail.com>
wrote:
> Hi Tornsten,
>
> Not sure to be able to attend the call, so here is a list of comments in
> any case:
>
> 1. Using the User Info endpoint looks effectively like the good way to
> split proofing from authentication. I recognize the value o*f:*
> - *organization* as this might have been done by the OP or a 3rd
> party
> - *date* but this should more reflect *date_of_proofing* [see point
> 2]
> - And then we should have *date_of_next_proofing* [see point 2]:
> timeout that is related to proofing, helping the RP to know when it should
> callback for an update
> - This raise the question of how to notify RP if proofing is
> revoked proven invalid before expiry.
> 2. Your proposition sounds like *Vector of Trust* which emphases
> *SP-800-63-3*
> - I think we should try to match it instead of trying to develop a
> parallel initiative
> - For example:
> - *Method* and *Agent* fields are already part of assurance
> evaluation in *SP-800-63-3* model
> - The Identity document depending of the assurance level
> targeted can be more than one:
> - A combination of multiple lower strength document can be
> equivalent to stronger strength document [Disclaimer: I will give a talk
> about this at EIC 2019]
> - You don't want / won't be able to represent all possible
> combination and the Identity Assurance Level has already done the job for
> you if you trust the OP.
> - So, *Type* field, if necessary, should focus on strength of
> evidence only not exact type of evidence:
> - For example: "Two strong + 1 weak", "Two superior", etc.
> - But even there, two different values may reflect in the
> same assurance level which should be your only base for risk evaluation at
> the RP
> - Note that a high assurance level proofing under a low-level
> authentication assurance lowers the overall assurance level of the
> transaction. That's where the *VoT* proves handy as it carries
> the whole information.
> - Finally, we already know how to map *SP-800-63-3* to *OMB *model
> and *eIDAS *model [I call them the *Matrix of Trust*]
> 3. I think it is very dangerous, sensible, and risky to exchange
> document information (id, expiry date, attributes) between OP and RP:
> - This is against data minimization;
> - This will be a new set of PII to secure at RP;
> - This will a new external data processing to declare at OP and for
> which OP SHALL gain the consent for;
> - If the OP is Trusted, a formal attestation that an IALx process
> has been performed SHALL be enough.
> - If x is lower than y (RP lower bound for risk acceptance) then
> it will be the RP accountability to switch to a higher assuring OP or to
> perform the missing proofing steps through local document collection and
> validation
>
>
> Best regards,
>
> Jeff
>
> Le jeu. 14 févr. 2019, à 08 h 06, Torsten Lodderstedt <
> torsten at lodderstedt.net> a écrit :
>
>> Hi Jeff,
>>
>> I agree that authentication and identity assurance must be treated
>> separately. The proposal is based on that concept (see intro).
>>
>> kind regards,
>> Torsten.
>>
>> > Am 12.02.2019 um 20:53 schrieb Jeff LOMBARDO <jeff.lombardo at gmail.com>:
>> >
>> > Thanks Torsten, that's very interesting to see new use cases poping up.
>> Great initiative.
>> >
>> > I will read carefully as I'm very attached to 63A and even if as a
>> starter I tend to thing like Tom (and by extension John.
>> >
>> > Best,
>> >
>> > JF
>> >
>> > Le lun. 11 févr. 2019, à 15 h 26, Tom Jones via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> a écrit :
>> > At a recent conference on strong identities (dec 10-11 redmond) John
>> brady suggested that we needed to separate identity claims from
>> authentication.
>> >
>> > I strongly support John’s concept.
>> >
>> > From my perspective what that means is that the OP should be primarily
>> in the business of authentication.
>> >
>> > Verified claims should not be mixed into that same basket.
>> >
>> > I would strong support creating some sort of “attribute provider”
>> (whatever) to supplied claims.
>> >
>> > Note that the verified claims working group ahs a different meaning for
>> verified.
>> >
>> > I believe to avoid confusion this concept needs a different name, like
>> validated claims.
>> >
>> >
>> >
>> > thx ..tom
>> >
>> >
>> >
>> > From: Hjelm, Bjorn via Openid-specs-ab
>> > Sent: Monday, February 11, 2019 11:35 AM
>> > To: Artifact Binding/Connect Working Group; Torsten Lodderstedt
>> > Cc: Hjelm, Bjorn; Paul Grassi
>> > Subject: Re: [Openid-specs-ab] [E] OpenID Connect for Identity
>> Proofing(Proposal)
>> >
>> >
>> >
>> > Torsten,
>> >
>> > Thank you for submitting this draft. I see a clear need for this
>> functionality. Besides support for NIST SP 800-63A, I would also like to
>> discuss how this work aligns with some of the discussions in the iGov WG
>> about developing support for NISTIR 8112.
>> >
>> >
>> >
>> > Looking forward to a productive WG discussion.
>> >
>> >
>> >
>> > BR,
>> >
>> > Bjorn
>> >
>> >
>> >
>> > On 2/9/19, 4:41 AM, "Openid-specs-ab on behalf of Torsten Lodderstedt
>> via Openid-specs-ab" <openid-specs-ab-bounces at lists.openid.net on behalf
>> of openid-specs-ab at lists.openid.net> wrote:
>> >
>> >
>> >
>> > Hi all,
>> >
>> >
>> > please find attached a document specifying an OpenID Connect
>> Extension for the purpose of strong Identity Proofing. On behalf of
>> yes.com, I would be delighted to contribute this document to the
>> AB/Connect Working Group.
>> >
>> >
>> > Background: At IIW I held a session about Identity Proofing with
>> OpenID Connect to get a feeling regarding the communities appetite to
>> standardize an OpenID Extension for this important but also challenging
>> topic. The feedback was tremendous so I started to work on this
>> specification. It is based on yes.com’s experience with strong identity
>> attestation in highly regulated contexts in the European Union, mainly in
>> Germany. For example, it will be used to attest user identities in the
>> context of creating Qualified (Remote) Electronic Signature according to
>> eIDAS. This kind of signature is legally equivalent to a traditional (wet)
>> signature on paper.
>> >
>> >
>> > The approach taken is focused on fulfilling the business
>> requirements for natural person identification in the EU. So my assumption
>> (and hope) is we together as a WG will refine and enhance the concept to
>> cover the requirements of jurisdictions around the world. I look forward to
>> having productive discussions.
>> >
>> >
>> > best regards,
>> >
>> > Torsten.
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> > Openid-specs-ab mailing list
>> >
>> > Openid-specs-ab at lists.openid.net
>> >
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> >
>> >
>> >
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190214/c836c3fc/attachment.html>
More information about the Openid-specs-ab
mailing list