[Openid-specs-igov] iGov Profile - suggestions for User Identifiers and Claim History

[Adam Cooper]

Re the historical attribute question the metadata does actually help...

In Currency Metadata you have the Last Verification element which denotes
the last point in time when the attribute was "verified as being true and
belonging to the specified individual". This could be used to indicate the
point at which an attribute become a historic attribute rather than
current.

As for the historic attributes (claims) themselves I will have to bow to
the OIDC experts but in JSON it would be useful to express these as arrays
of objects (I have included the metadata for discussion) e.g.

"name-history":[
    {"given_name":"Jane", "family_name":"Jones", "Last
Verification":"2001-11-07"},
    {"given_name":"Jane", "family_name":"Smith", "Last
Verification":"2016-03-01"}
]

Guessing that's not simple in OIDC claims but hope to be corrected...



On 2 September 2016 at 02:29, Grassi, Paul A. (Fed) <paul.grassi at nist.gov>
wrote:

> As discussed, our metadata proposed model in draft.  All elements
> optional, though I expect us to potentially say ‘metadata element A is
> meaningless without C’.  Doesn’t answer the historical question.
>
>
>
> https://pages.nist.gov/NISTIR-8112
>
>
>
> Paul
>
>
>
>
>
>
>
> *From: *Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net> on
> behalf of Justin Richer via Openid-specs-igov <openid-specs-igov at lists.
> openid.net>
> *Reply-To: *Justin Richer <jricher at mit.edu>
> *Date: *Saturday, August 27, 2016 at 6:23 PM
> *To: *Adam Cooper <adam.cooper at digital.cabinet-office.gov.uk>
> *Cc: *Openid-specs-igov <openid-specs-igov at lists.openid.net>
> *Subject: *Re: [Openid-specs-igov] iGov Profile - suggestions for User
> Identifiers and Claim History
>
>
>
> One issue is that we don’t say how historical information is represented.
> We need to extend the data model appropriately for this.
>
>
>
>  — Justin
>
>
>
> On Aug 27, 2016, at 10:01 AM, Adam Cooper via Openid-specs-igov <
> openid-specs-igov at lists.openid.net> wrote:
>
>
>
> Hi all,
>
>
>
> In followup to this week's call I had a couple of actions for suggestions
> to add to the profile based on UK and EU government backed identity
> schemes.
>
>
>
> *User Identifiers*
>
>
>
> In the profile we currently have the following sub vales defined as part
> of the ID Token:
>
>
>
> sub
>
> The identifier of the user. SHOULD be a pairwize annonymous identifier,
> and be unique per client to prevent linkability and traceability between
> clients.
>
>
>
>
>
> Based on the eIDAS interoperability specifications (which covers 28 EU
> member states including for now the UK), I would suggest that we provide
> the additional guidance for providers when creating "sub" values:
>
>
>
> As a baseline requirement the "sub" identifier value should not include
> elements that directly identify the Principal i.e. the user. This follows
> the requirement for a persistent name identifier in other international
> identity standards such that persistent identifiers MUST be constructed
> using pseudo-random values that have no discernible correspondence with the
> subject's actual identifier (for example, username).
>
>
>
> Hashing of "sub" identifier values is permitted although this is not
> mandated by this profile.
>
>
>
> The "sub" identifier value MUST NOT contain any whitespace. It is
> recommended that the "sub" identifier value is at least 32 characters in
> length.
>
>
>
> Optionally we may also wish to include some guidance about the stability
> of uniqueness identifiers:
>
>
>
> The Uniqueness Identifier represented by the "sub" (subject) claim value
> shall remain unchanged for the lifetime of the identity account (as created
> by the underlying identity scheme). A Uniqueness Identifier shall never be
> reused, e.g. a new Uniqueness Identifier shall not match a Uniqueness
> Identifier that has been deleted.
>
>
>
> Any service that consumes assertions of identity must assume that the
> Uniqueness Identifier presented for a particular person (natural or legal)
> may change over time e.g. where the user’s digital identity is replaced or
> repaired. This should be handled by a consuming service using the same
> matching process as used when an identity is first encountered utilising
> the set of identity attributes used to identify the Principal (i.e. user)
> within the service.
>
>
>
>
>
> *Claim History*
>
>
>
> Where available previous name, address and date of birth claim values may
> be provided by the UserInfo Endpoint. These additional historic claim
> values, where available, should be provided to increase the possibility of
> a successful match to a government "account" where the user has changed
> personal details recently or visits the digital service being accessed
> infrequently.
>
>
>
>
>
> Cheers,
>
>
>
> A
>
>
>
>
>
> --
>
> Adam Cooper
>
> Identity Assurance Programme
>
> Government Digital Service
>
> 125 Kingsway, London, WC2B 6NH
>
>
>
> Tel: 07973 123 038
>
> official: adam.cooper at digital.cabinet-office.gov.uk
>
> official sensitive: adam.cooper at govdigital.gsi.gov.uk
>
>
>
> _______________________________________________
> Openid-specs-igov mailing list
> Openid-specs-igov at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-igov
>
>
>



-- 
Adam Cooper
Identity Assurance Programme
Government Digital Service
125 Kingsway, London, WC2B 6NH

Tel: 07973 123 038
official: adam.cooper at digital.cabinet-office.gov.uk
official sensitive: adam.cooper at govdigital.gsi.gov.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20160902/fa11c0e4/attachment.html>