<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks Jaap for doing this work and the proposals.</p>
    <p>I find the purpose URNs highly useful. This makes it possible for
      providers or an ecosystem to have a well defined common set of
      purposes, which will also act as sort of guideline for client
      applications on what grounds verified claims can be requested.
      Consent for users can also be made more consistent and informative
      for users.</p>
    <p>Vladimir<br>
    </p>
    <div class="moz-cite-prefix">On 11/05/2020 17:38, Jaap Francke via
      Openid-specs-ekyc-ida wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7A9F9749-5033-4E20-8F35-FDFDABDF1BC2@iwelcome.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
        space; line-break: after-white-space;" class="">
        <div class="">Hi Torsten, Achim and others</div>
        <div class=""><br class="">
        </div>
        <div class="">Resuming our previous email conversation….</div>
        <div class=""><br class="">
        </div>
        <div class="">On the topic of RP-specific scopes. Yes I’ve seen
          this in practice, maybe not in eIDAS context, but in general
          with OAuth, we have seen various situations where custom
          claims are requested via custom scopes, which may be RP
          specific. I think Achim’s proposal addresses my initial
          remark.</div>
        <div class=""><br class="">
        </div>
        <div class="">On the the topic of consent and legal aspects. I
          started drafting proposed texts and changes as you suggested
          and came to realize that in my view a claim may be requested
          for one or multiple purposes. GDPR mandates that legal grounds
          for processing need to be addressed at a granular level.
          Processing purposes should not be bundled. </div>
        <div class="">The point from my previous email was to not make
          an assumption on how legal aspects are addressed in the
          protocol itself. So to facilitate both of ‘my’ requirements, I
          think the protocol should maybe allow for the following:</div>
        <div class="">- RP can indicate for what purpose(s) it is
          requesting a (verified) claim</div>
        <div class="">- The OP can indicate which purpose(s) it knows
          that are somehow ‘legally covered’ (which applies both to
          regular and verified claims)</div>
        <div class="">- Instead of a processing purpose being a
          descriptive string, it could be a urn.</div>
        <div class="">In response to Achim’s remark, I do believe that
          data protection details should be covered by a specification.
          The challenge is to not do so in a flexible way. Another
          option could be to take the whole concept of ‘purpose’ out of
          the spec, since it is not by definition related to the concept
          of VERIFIED claims.</div>
        <div class=""><br class="">
        </div>
        <div class="">So as a reult of these ideas of mine, I am
          proposing enhancements of the specifications as per ‘below'. I
          hope it makes sense (and also hope it is well formulated, not
          being a native speaker sometimes makes it a bit difficult for
          me to express myself clearly).</div>
        <div class=""><br class="">
        </div>
        <div class="">Kind regards,</div>
        <div class=""><br class="">
        </div>
        <div class="">Jaap Francke</div>
        <div class=""><br class="">
        </div>
        <div class=""><br class="">
        </div>
        <div class="">-------</div>
        <div class=""><br class="">
        </div>
        <div class="">
          <div class="">SECTION 4.4 Lawful purposes Element</div>
          <div class="">This specification defines a generic mechanism
            to add purposes to claims. Since both verified cliams and
            regular claims transfer personal data the purposes can be
            indicated for any of such claims. </div>
          <div class=""><br class="">
          </div>
          <div class="">
            <p id="section-4-5" style="padding: 0px; margin: 0px 0px
              1em; color: rgb(34, 34, 34); font-family: "Noto
              Sans", Arial, Helvetica, sans-serif; font-size: 14px;
              font-variant-ligatures: normal; orphans: 2; widows: 2;
              background-color: rgb(255, 255, 255);" class="">
              The normative definition is given in the following.<a
href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#section-4-5"
                class="pilcrow" style="text-decoration: none; z-index:
                2; color: rgb(102, 102, 102); visibility: visible;"
                moz-do-not-send="true">¶</a></p>
            <p id="section-4-6" style="padding: 0px; margin: 0px 0px
              1em; color: rgb(34, 34, 34); font-family: "Noto
              Sans", Arial, Helvetica, sans-serif; font-size: 14px;
              font-variant-ligatures: normal; orphans: 2; widows: 2;
              background-color: rgb(255, 255, 255);" class="">
              <code style="background-color: rgb(249, 249, 249);
                font-family: "Roboto Mono", monospace;
                font-size: 13.3px;" class="">lawful_purposes</code>:
              Object or array containing one or more purposes for
              processing of a user's data by RP and for which the OP
              knows a lawful basis exists. A purpose may be a
              descriptive sentence or may be a urn for a previously
              established processing purpose.</p>
            <div class="">Note: An OP may decide to provide a claim
              without knowledge of a lawfull basis for the specific
              user. The protocol does not mandate a specific devision of
              responsibilities over the OP and RP.</div>
          </div>
          <div class=""><br class="">
          </div>
          <div class="">Note: User’s consent is a lawful basis. Another
            example may be a legal obligation for the RP.</div>
          <div class=""><br class="">
          </div>
          <div class="">Note: An RP and a OP may agree on a set of data
            processing purposes and refer to those using a urn. Part of
            tis agreement may be a their lawful bases, user’s consent on
            Privacy Policies and how to obtain consent, etc. At the urn,
            more generic details about the lawful basis may be made
            available, such as an indicator for the Data Controller
            (legally responsible entity), etc.</div>
          <div class=""><br class="">
          </div>
          <div class="">
            <p id="section-5.1-11" style="padding: 0px; margin: 0px 0px
              1em; color: rgb(34, 34, 34); font-family: "Noto
              Sans", Arial, Helvetica, sans-serif; font-size: 14px;
              font-variant-ligatures: normal; orphans: 2; widows: 2;
              background-color: rgb(255, 255, 255);" class="">
              Example:</p>
            <div id="section-5.1-12" style="position: relative; margin:
              0px; color: rgb(34, 34, 34); font-family: "Noto
              Sans", Arial, Helvetica, sans-serif; font-size: 14px;
              font-variant-ligatures: normal; orphans: 2; widows: 2;
              background-color: rgb(255, 255, 255);" class="">
              <pre class="lang-json sourcecode" style="background-color: rgb(249, 249, 249); font-family: "Roboto Mono", monospace; border: 1px solid rgb(238, 238, 238); margin-top: 0px; margin-bottom: 0px; padding: 1em; overflow-x: auto; max-width: calc(100% - 22px); font-size: 13.3px; line-height: 1.12;">{
   "userinfo":{
      "verified_claims":{
         "verification": {
            "trust_framework": “<span style="font-size: 13.3px;" class="">ial_example_gold"</span>
         },
         "claims":{
            "given_name":"Max",
            "family_name": "Meier",
            "birthdate": "0000-03-22"
         }
      }
      “lawful_purposes" : {
         "given_name" : {
            "To make communication look more personal"
         }
         "birthdate" : {
            "To validate the user is an adult and parental responsibilities are not applicable",
            “The user has reached the age of majority"
         }
      }
   }
}</pre>
            </div>
            <div class=""><br class="">
            </div>
          </div>
        </div>
        <div class=""><br class="">
        </div>
        <div class=""><br class="">
        </div>
        <div class="">SECTION 5.1.</div>
        <div class=""><br class="">
        </div>
        <div class="">
          <p id="section-5.1-9" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            This specification introduces the additional field <code
              style="background-color: rgb(249, 249, 249); font-family:
              "Roboto Mono", monospace; font-size: 13.3px;"
              class="">purposes</code> to allow an RP to state the
            purpose(s) for the transfer of a certain End-User Claim it
            is asking for. The field <code style="background-color:
              rgb(249, 249, 249); font-family: "Roboto Mono",
              monospace; font-size: 13.3px;" class="">purposes</code> can
            be a member value of each individually requested Claim. A
            Claim can have more than one associated purpose.</p>
          <p id="section-5.1-10" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            <code style="background-color: rgb(249, 249, 249);
              font-family: "Roboto Mono", monospace;
              font-size: 13.3px;" class="">purposes</code>: OPTIONAL. An
            array of string describing the purposes for obtaining a
            certain End-User Claim from the OP. </p>
          <p id="section-5.1-10" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            Each purpose MUST NOT be shorter than 3 characters or longer
            than 300 characters. If this rule is violated, the
            authentication request MUST fail and the OP return an error <code
              style="background-color: rgb(249, 249, 249); font-family:
              "Roboto Mono", monospace; font-size: 13.3px;"
              class="">invalid_request</code> to the RP. A purpose may
            be a descriptive sentence or may be a urn for a previously
            established processing purpose.</p>
          <p id="section-5.1-10" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            The OP MAY display one or more of the purposes on a user
            screen(s) in order to inform the user about the designated
            use of the data to be transferred. The lawful basis for the
            transfer of the personal data may differ for different
            implementations and the legal aspects are out of scope of
            this specification. A specific purpose may or may not
            require that the user’s consent is obtained by either OP or
            RP. If the parameter <code style="background-color: rgb(249,
              249, 249); font-family: "Roboto Mono",
              monospace; font-size: 13.3px;" class="">purpose</code> is
            not present in the request, the OP MAY display a value that
            was pre-configured for the respective RP. For details on UI
            localization, see <a
href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#purpose"
              class="xref" style="text-decoration: none; z-index: 2;
              color: rgb(34, 34, 238);" moz-do-not-send="true">Section 8</a>.</p>
          <p id="section-5.1-10" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
          </p>
          <p id="section-5.1-11" style="padding: 0px; margin: 0px 0px
            1em; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            Example:</p>
          <div id="section-5.1-12" style="position: relative; margin:
            0px; color: rgb(34, 34, 34); font-family: "Noto
            Sans", Arial, Helvetica, sans-serif; font-size: 14px;
            font-variant-ligatures: normal; orphans: 2; widows: 2;
            background-color: rgb(255, 255, 255);" class="">
            <pre class="lang-json sourcecode" style="background-color: rgb(249, 249, 249); font-family: "Roboto Mono", monospace; border: 1px solid rgb(238, 238, 238); margin-top: 0px; margin-bottom: 0px; padding: 1em; overflow-x: auto; max-width: calc(100% - 22px); font-size: 13.3px; line-height: 1.12;">{
   "userinfo":{
      "verified_claims":{
         "verification": {
            "trust_framework": null
         },
         "claims":{
            "given_name":{
               "essential":true,
               "purposes": [
                  "To make communication look more personal"
               ]
            },
            "family_name":{
               "essential":true
            },
            "birthdate":{
               "purposes": [
                  "To send you best wishes on your birthday”,
                  "To validate the user is an adult and parental responsibilities are not applicable"
            }
         }
      }
   }
}</pre>
          </div>
          <div class=""><br class="">
          </div>
        </div>
        <div class=""><br class="">
        </div>
        <div class=""><br class="">
        </div>
        <div class=""><br class="">
        </div>
        <br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 1 May 2020, at 18:25, Torsten Lodderstedt
              <<a href="mailto:torsten@lodderstedt.net" class=""
                moz-do-not-send="true">torsten@lodderstedt.net</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class=""><span style="caret-color: rgb(0, 0, 0);
                font-family: Helvetica; font-size: 12px; font-style:
                normal; font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">Hi Jaap,</span><br
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <blockquote type="cite" style="font-family: Helvetica;
                font-size: 12px; font-style: normal; font-variant-caps:
                normal; font-weight: normal; letter-spacing: normal;
                orphans: auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px; text-decoration: none;"
                class="">
                On 1. May 2020, at 15:23, Jaap Francke <<a
                  href="mailto:jaap.francke@iwelcome.com" class=""
                  moz-do-not-send="true">jaap.francke@iwelcome.com</a>>
                wrote:<br class="">
                <br class="">
                Hi Torsten,<br class="">
                <br class="">
                Thanks for your reply. My comments are also inline.<br
                  class="">
                <br class="">
                <blockquote type="cite" class="">
                  <blockquote type="cite" class=""><br class="">
                    <a
href="https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html"
                      class="" moz-do-not-send="true">https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html</a><br
                      class="">
                    <br class="">
                    The "OIDC for identity Assurance” specs introduce a
                    number of claims, in addition to the ones
                    specificied by OIDC core.<br class="">
                    In OIDC Core, there are 2 mechanisms to request
                    claims:<br class="">
                    - one is by usage of OAuth-scopes, (section 5.4 of
                    Core spec)<br class="">
                    - one by usage of the “claims” parameter in the
                    request. (section 5.5 of Core spec)<br class="">
                    Section 5 of the OIDC—identity-assurance specs
                    indicate the usage of the claims pararameter. This
                    may suggest it’s the only mechanism to be used in
                    the context of Identity Assurance.<br class="">
                    My view is that also the ’scope’ mechanism should be
                    supported and may even be preferred for certain use
                    cases.<br class="">
                    Please enhance the specification to be more explicit
                    about usage of scopes as a means to request verified
                    claims.<br class="">
                    <br class="">
                    Usage of ’scope’ to request verified claims makes
                    sense to me because in a typical “identity
                    landscape” the requested claims do not vary on a
                    request-by-request basis, but instead are a
                    reflection of an RP’s functionality which can be
                    rather static. By pre-defining/configuring scopes at
                    the OP (potentially in terms of ’essential’,
                    ’trust_framework’, etc..), the scope is essentially
                    a profile of the claim request. This would not only
                    simplify the protocol implementation both at the RP
                    and OP side, but it would also make it easier for
                    the OP to make the authorisation decision whether or
                    not the RP will be granted the requested verified
                    claims. 'It is at the discretion of the OP to decide
                    whether the requested verification data is provided
                    to the RP.’ Making this decision is much easier when
                    a request includes a scope as a reference to a
                    predefined profile of requested end-user claims and
                    associated verification data. My suggestion is to
                    consider including such a mechanism in the
                    specifications.<br class="">
                  </blockquote>
                  <br class="">
                  What do you have in mind? I agree a certain RP or
                  deployment could define scope values as short cut to
                  request certain verified claims. However, the number
                  and value range of verification elements + the number
                  of end user claims creates is so big I cannot envision
                  how the spec could define concrete scope values.<br
                    class="">
                </blockquote>
                <br class="">
                Yes, so what i had in mind is that the spec would
                acknowledge the practice of defining a ‘custom' scope
                value as shortcut to request certain claims. The current
                spec only mentions the ‘claims’ request parameter as
                mechanism to request claims, which I see as somewhat
                ambigous The spec could mention both mechanisms as valid
                options and leave it to the the implementor to make a
                choice which mechanism is more appropriate.<span
                  class="Apple-converted-space"> </span><br class="">
                My preference is the ’scope’ approach, since it fits
                into what i see as a typical situation where the
                interaction between RP and OP has a more ’static’
                nature.<span class="Apple-converted-space"> </span><br
                  class="">
                I could imagine the spec even stating perceived
                pros&cons of both approaches. Claims approach gives
                a lot of flexibility to vary on a request-by-request
                basis. The scope approach is easier in situations where
                there is a ’static’ interaction between OP and RP; i.e.
                an RP may always want to receive the same set of claims,
                for the same data processing and purpose, etc.<br
                  class="">
              </blockquote>
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">I assume the interaction can be
                static for a certain RP with a certain OP. This would
                call for RP-specific scope values. Have you ever seen
                this in practice? I haven’t.<span
                  class="Apple-converted-space"> </span></span><br
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <blockquote type="cite" style="font-family: Helvetica;
                font-size: 12px; font-style: normal; font-variant-caps:
                normal; font-weight: normal; letter-spacing: normal;
                orphans: auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px; text-decoration: none;"
                class="">
                <br class="">
                <blockquote type="cite" class="">Additionally, the spec
                  no longer defines values for trust frameworks,
                  verification methods and evidence, i.e. there are
                  unknown values from a spec perspective.<br class="">
                  <blockquote type="cite" class=""><br class="">
                    My second observation is about the optional
                    ‘purpose’ parameter in a claims request. The specs
                    state that the OP MUST display this purpose in the
                    respective user consent screen(s) in order to inform
                    the user about the designated use of the data to be
                    transferred or the authorization to be approved. If
                    the parameter purpose is not present in the request,
                    the OP MAY display a value that was pre-configured
                    for the respective RP.’<span
                      class="Apple-converted-space"> </span><br class="">
                    This part of the specification assumes or seems to
                    imply that the user gets a consent screen every time
                    that verified data is requested. I think that this
                    is not realistic:<br class="">
                    - it is common practice that certain consents are
                    included in a Privacy Policy (PP) and/or Terms of
                    Service (ToS). The user gives his consent once and
                    the consent is persisted at the OP for future
                    purposes.<br class="">
                  </blockquote>
                  <br class="">
                  Are you referring to ToS/PP of the RP or the OP?<br
                    class="">
                </blockquote>
                <br class="">
                Good question. I think it could be either one or maybe
                even both. My understanding of the European GDPR is that
                the OP may need the user’s consent to provide data to
                the RP and the RP needs a legal ground to collect a
                person’s data. This is assuming that RP and OP are
                different legal entities / Data Controllers. Different
                scenario’s can also be possible where OP and/or RP (from
                a legal perspecrive) could be Data Controller or Data
                Processor. Moreover, i think legal entities can even
                delegate the responsibility to get a user’s consent (if
                consent is the legal ground that is applicable)<br
                  class="">
                <br class="">
                <br class="">
                <blockquote type="cite" class="">
                  <blockquote type="cite" class="">- if not in PP or
                    ToS, a consent screen may be presented only ‘once’
                    and the user’s consent is taken to be valid for the
                    next 6 months (as an example)<br class="">
                    - in some situations there are other legal
                    grounds/reasons/purposes to request the claims and
                    verification data. Besides ‘consent’, the European
                    GDPR indicates other legal grounds (contract, vital
                    interest, legal obligation, ..). When an RP asks for
                    a verified claim, it may do so based on a legal
                    obligation and the user’s consent would not be
                    needed.<br class="">
                    - Privacy regulations aim at situations where
                    personal data is exchanged between legal entities
                    (data controllers, data processors). From an IT
                    perspective, the OP and the RP may be operated by
                    the same entity (for example an Insurance company as
                    data controller that is both the data controller for
                    the OP and various RPs) so consent would not apply
                    at the moment of requesting the claim. The consent
                    should already have been given at the moment the
                    personal data was provided to the OP.<br class="">
                    My proposal would be that the ‘purpose’ could be a
                    string (as per current specification) or a reference
                    to a ‘purpose’ that has already been established
                    somewhere. This approach makes it easier for the OP
                    to make the decision to provide the requested data
                    or not.<br class="">
                  </blockquote>
                  <br class="">
                  I agree the text is too strong. The purpose should be
                  used to further inform the user in case a user consent
                  screen is required. I will try to change the text
                  accordingly.<br class="">
                </blockquote>
                <br class="">
                Extending my previous replies, my suggestion would be
                that the eKYC standard would not ‘enforce’ or assume
                whatever particular legal set-up of responsibilities,
                but instead facilitate any legal context and/or
                interpretation.<br class="">
                I think the way to do so would be to include the
                possibility to include one or more references to types
                of data processing (‘purposes’) that should somehow be
                legally covered.<br class="">
                How this ‘legal cover’ is arranged for may vary per
                implementation:<br class="">
                - Is the OP Data Controller or Data Processer? Is the RP
                Data Controller or Data Processer?<br class="">
                - Does the intended data processing require the user’s
                consent or does one of the other legal grounds apply?<br
                  class="">
                - Did RP and OP agree on some delegation about getting
                the user’s consent (if needed)?<br class="">
                In this way the protocol can facilitate any set-up in a
                transparant way, without making assumptions on legal
                reponsibilities at either OP and/or RP.<br class="">
              </blockquote>
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">What does this mean to protocol
                constructs? Can you please suggest concrete
                changes/text?</span><br style="caret-color: rgb(0, 0,
                0); font-family: Helvetica; font-size: 12px; font-style:
                normal; font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <blockquote type="cite" style="font-family: Helvetica;
                font-size: 12px; font-style: normal; font-variant-caps:
                normal; font-weight: normal; letter-spacing: normal;
                orphans: auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px; text-decoration: none;"
                class="">
                <br class="">
                <br class="">
                <blockquote type="cite" class="">
                  <blockquote type="cite" class=""><br class="">
                    Furthermore, it could be considered to extend the
                    list of verification methods with the ones defined
                    by NISTIR 8112.<br class="">
                  </blockquote>
                  <br class="">
                  You mean „Document Verification”, “Record
                  Verification”, “Document Verification with Record
                  Verification”, “Proof of Possession”, “Probabilistic
                  Verification”, „Not Verified”? We could add this to
                  our Wiki. May I ask you to add the values?<br class="">
                </blockquote>
                <br class="">
                Yes that’s what I meant. I need to familiarize with the
                wiki.<br class="">
              </blockquote>
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">You may find the existing
                definitions at<span class="Apple-converted-space"> </span></span><a
href="https://bitbucket.org/openid/ekyc-ida/wiki/identifiers"
                style="font-family: Helvetica; font-size: 12px;
                font-style: normal; font-variant-caps: normal;
                font-weight: normal; letter-spacing: normal; orphans:
                auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px;" class=""
                moz-do-not-send="true">https://bitbucket.org/openid/ekyc-ida/wiki/identifiers</a><span
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">.</span><br style="caret-color:
                rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;
                font-style: normal; font-variant-caps: normal;
                font-weight: normal; letter-spacing: normal; text-align:
                start; text-indent: 0px; text-transform: none;
                white-space: normal; word-spacing: 0px;
                -webkit-text-stroke-width: 0px; text-decoration: none;"
                class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">Let me know if you want to
                contribute changes, the I would give you the respective
                permissions.<span class="Apple-converted-space"> </span></span><br
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">best regards,</span><br
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <span style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none; float: none; display: inline
                !important;" class="">Torsten.<span
                  class="Apple-converted-space"> </span></span><br
                style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <br style="caret-color: rgb(0, 0, 0); font-family:
                Helvetica; font-size: 12px; font-style: normal;
                font-variant-caps: normal; font-weight: normal;
                letter-spacing: normal; text-align: start; text-indent:
                0px; text-transform: none; white-space: normal;
                word-spacing: 0px; -webkit-text-stroke-width: 0px;
                text-decoration: none;" class="">
              <blockquote type="cite" style="font-family: Helvetica;
                font-size: 12px; font-style: normal; font-variant-caps:
                normal; font-weight: normal; letter-spacing: normal;
                orphans: auto; text-align: start; text-indent: 0px;
                text-transform: none; white-space: normal; widows: auto;
                word-spacing: 0px; -webkit-text-size-adjust: auto;
                -webkit-text-stroke-width: 0px; text-decoration: none;"
                class="">
                <blockquote type="cite" class=""><br class="">
                  --<span class="Apple-converted-space"> </span><br
                    class="">
                  Openid-specs-ekyc-ida mailing list<br class="">
                  <a
                    href="mailto:Openid-specs-ekyc-ida@lists.openid.net"
                    class="" moz-do-not-send="true">Openid-specs-ekyc-ida@lists.openid.net</a><br
                    class="">
                  <a
                    href="http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida"
                    class="" moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ekyc-ida</a></blockquote>
              </blockquote>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>