[Openid-specs-ab] Opened-connect-4-identity-assurance-02

Tom Jones thomasclinganjones at gmail.com
Sun Jul 14 21:27:10 UTC 2019


You may as well just copy the existing piece from the kantara consent
receipt. Sorry for the PDF nastiness.

5.3 purposes 378 REQUIRED: An array that contains one or more items where
each item represents 379 one Purpose. It is only required for the JSON
encoding of a Consent Receipt. 380 JSON: purposes, type: array 381 4.5.4
Purpose 382 OPTIONAL: A short, clear explanation of why the PII is
required. 383 JSON: purpose, type: string 384 4.5.5 Purpose Category 385
REQUIRED: The reason the PII Controller is collecting the PII. Example
Purpose 386 Categories currently in use are available on the Kantara
Consent & Information 387 Sharing Work Group (CISWG) Wiki page 388 (
https://kantarainitiative.org/confluence/x/74K-BQ). This field MUST contain
a non-389 empty string. 390 JSON: purposeCate


thx ..Tom (mobile)

On Sun, Jul 14, 2019, 9:57 AM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Marcos,
>
> > On 4. Jun 2019, at 13:18, Marcos Sanz <sanz at denic.de> wrote:
> >
> > Hi Torsten,
> >
> > (despite subject I am now refering to the latest version -04)
> >
> >>> - Section 3.1: Re "nationality" it looks like only one country code is
> >
> >>> allowed. Is it in scope to deal with multiple nationalities?
> >>
> >> Good question! I will created a corresponding ticket (
> >
> https://bitbucket.org/openid/connect/issues/1092/support-multiple-nationalities
> > ).
> >>
> >> There are indeed people having more than a single nationality.
> >> The question is whether the IDP will verify those and will be able to
> > attest them.
> >>
> >> In our original setting (German AML), the bank will verify _a_
> > nationality but not
> >> necessarily all of them.
> >>
> >> There is also a structural challenge. If we modify the syntax to allow
> > for multiple nationalities, is there a need to link every
> >> entry in the array to a certain evidence?
> >
> > At the moment the spec does not link verified data to its respective
> > evidence at all, even when there are multiple evidences (s. for instance
> > the example in section 6.2 with ID document AND utility bill), so I
> don't
> > think we would (or actually do) need that capability. On the other hand,
> > you might be right with regard to an entity verifying one nationality
> and
> > not all of them. So I don't really need the multiple nationalities
> > feature.
> >
> > What I just came up with and actually think to be more important than
> > multiple nationalities (warning: I am not an expert in this topic!) is
> the
> > fact that the ICAO Machine Readable Passports specification asserts
> > nationality by means of their ICAO codes (
> > https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf), which
> > expand ISO 3166 because they also have to deal with UN travel documents
> > and other various issuing authorities. ICAO even reserve nationality
> codes
> > for stateless people.  For a good summary read
> > https://www.iso.org/news/2011/04/Ref1604.html rather than the ICAO PDF.
> >
> > So while ISO3166 initially seemed to us initially like the natural fit
> to
> > describe "issuer country" and "nationality", we might be excluding
> > (discriminating?) identities from being describable with our spec.
> >
> > Are ICAO codes maybe the better way to go?
>
> Sounds reasonable to me. I created a ticket
> https://bitbucket.org/openid/connect/issues/1099/use-icao-codes-for-nationality-and-issuer
> in order to discuss your proposal with the group.
>
> >
> >>> - Section 4.1: If we agree that we should be extensible wrt Trust
> >>> Frameworks, a sentence should be included here (or somewhere else)
> > that a)
> >>> the list in section 12.1 is only the initial list b) that Trust
> > Frameworks
> >>> that are not understood in answers should be ignored and c) that
> > querying
> >>> for unknown (i.e. not announced in trust_frameworks_supported) Trust
> >>> Frameworks should maybe deliver a dedicated, still to be defined error
> >
> >>> (e.g. trust framework not supported)
> >>
> >> Enhanced text a bit. The challenge I see is to really establish the
> > required extension mechanism.
> >
> > Absolutely.
> >
> >> Created a corresponding ticket:
> >
> https://bitbucket.org/openid/connect/issues/1093/extensibility-how-do-we-support
> > [...]
> >> Created another ticket to bring this question to the WG’s attention:
> > https://bitbucket.org/openid/connect/issues/1094/how-to-
> >> treat-unknown-identifiers-in-claims
> >
> > Ok, let's track discussion there.
> >
> >>> - Section 8: This is a cool feature, which indeed we use in our
> > deployment
> >>> (we call it "reason" instead of "purpose", but the same semantics). As
> > a
> >>> matter of fact, we allow to specify a per-claim "reason" (which is
> >>> specially useful to differentiate among why some claims requested are
> >>> mandatory and some optional). We query like this (in order to be OIDC
> > core
> >>> compliant):
> >>> "userinfo": { "given_name": {"essential": true, "reason": "In order to
> >
> >>> create an account"}}
> >>> Do you think we could enrich "purpose" in this direction? And in any
> > case,
> >>> a usage example in section 8 would be helpful.
> >>
> >> Sure. Can you please suggest text?
> >
> > Actually I think now that the text, which is all about requesting user
> > claims, better belongs to section 5.1, right before the first note (and
> > there's no need at all for a section 8):
>
> I like your proposal! I also think both approaches will perfectly go
> together. Having a description of the overall purpose of the transaction
> makes a lot of sense in a lot of use cases, e.g. “I need to obtain this
> data because you want to sign up for a mobile subscription with me and I
> need to verify your identity”. On the other hand, having the ability to
> also state the purpose for acquiring an individual claim is valuable as
> well.
>
> So I would like to keep the transaction parameter and added your proposal.
>
> >
> > "
> > This specification introduces the request parameter purpose to allow a
> RP
> > to state the purpose for the transfer of the user data it is asking for.
> > The parameter purpose can be a member value of each individually
> requested
> > claim, but a claim cannot have more than one associated purpose.
> > purpose OPTIONAL. String describing the purpose for obtaining certain
> user
> > data from the OP. The 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 returns an error invalid_request to the RP.
> > 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. Purposes are free text
> > and, as such, it is up to the RP to perform localization of the message
> > (incl. choosing the appropriate language) according to user
> > context/preferences before issuing the request. If the parameter purpose
> > is not present in the request, the OP MAY display a generic purpose or a
> > value that was pre-configured for the respective RP.
> > Example:
>
> I incorporated your text with an exception, I did not include the option
> for the OP to display a generic purpose. I cannot imagine how a generic
> purpose could look like since it always depends on what the RP intends to
> do with the data.
>
> > {
> >   "userinfo":{
> >      "verified_person_data":{
> >         "claims":{
> >            "given_name":{"essential": true, "purpose": "To make
> > communication look more personal"},
> >            "family_name":{"essential": true},
> >            "birthdate":{"purpose": "To send you best wishes on your
> > birthday"}
> >         }
> >      }
> >   }
> > }
> > "
> >
> >
> >>> - Section 8: What about moving the final Note on XSS and the like to
> > the
> >>> (still empty) Security Considerations?
> >>
> >> Well, you are not the first reviewer to raise this. I would like to
> > leave it in section 8 for now because moving it into the
> >> security considerations section would require to first establish the
> > context, … this is about the purpose …
> >>
> >> I personally prefer to give security considerations with the feature
> > description since it is the right context and is directly
> >> actionable. If we in the end come to the conclusion the security
> > considerations section is the better place (== better for
> >> implementers to understand) I will happily move it there. Ok?
> >
> > Fine by me.
> >
> > One more thing: I noticed that section 7 introduces a new boolean
> element
> > (verified_person_data_supported) with exactly the same name as the
> > existing JSON array containing all claims supported and defined in the
> > very same section. That's a recipe for disaster ;->
>
> I agree. Fixed that.
>
> Thanks a lot!
> Torsten.
>
> >
> > Best regards,
> > Marcos
>
> _______________________________________________
> 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/20190714/fbb04a62/attachment.html>


More information about the Openid-specs-ab mailing list