[Openid-specs-ab] [E] OpenID Connect for Identity Proofing(Proposal)

Thu Feb 14 14:26:17 UTC 2019

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/26c94916/attachment.html>