[Openid-specs-ab] OpenID Connect for Identity Proofing (Proposal)
sanz at denic.de
Fri Feb 22 10:59:23 UTC 2019
> > - Page 10: The role of "max_age" is a bit strange: it is defined as
> > "field for the sub-element date of the verification sub-claim"
> > it's actually a way of introducing a (hidden) query syntax. When I
> > of it, it's an extension of the special three member values defined in
> > OIDC core section 5.5.1, that is, parallel to the existing reserved
> > keywords "essential", "value" and "values". Maybe it'd help to
> > define it that way. Do you understand what I mean?
> I think so. I would argue the whole representation extends the syntax of
the claims parameter payload by introducing nested claims
> + conditions on those nested claims.
> I would appreciate if you would come up with a text proposal.
This is what I had in mind:
Section 5.5 in OIDC Core defines how to request specific claims using the
"claims" parameter. Section 5.5.1 extends that query syntax and allows for
the member value of the claim being requested to be a JSON object with
additional information/constraints on the claim. For doing so it defines
three members ("essential", "value" and "values") with special query
meanings and allows for other special members to be defined (while stating
that any members that are not understood must be ignored).
This specification introduces a new such member "max_age".
"max_age" OPTIONAL Only applicable to claims that contain dates or
timestamps. Defines the maximum time (in seconds) to be allowed to elapse
since the value of the date/timestamp up to the point in time of the
request. The IDP should make the calculation of elapsed time starting from
the last valid second of the date value. The following is an example of a
request for claims where the verification process of the data is not
allowed to be older than 63113852 seconds.
"max_age" : "63113852"
"claims" : null
Admittedly, this is more generic than what you originally wrote, since it
allows for combinations of "max_age" with e.g.
"date_of_issuance"/"date_of_expiry" (combinations I still thought to be
useful). If this is not what you wanted or you plainly want to ban it, I
could slightly adjust the text.
> > - Page 11 introduces "transaction_id" and I was wondering whether this
> > the same as the "id" field introduced in page 4 or not, and then would
> > to either align names or explicitly explain the differences.
> That’s a different claim. Id refers to the verification process with the
IDP whereas transaction_id refers to the actual OpenID
> Connect transaction. It’s used to in dispute and audit scenarios to
trace back to the OIDC transaction, the OP is supposed to
> retain an audit log so the authentication and consent steps performed
can be followed.
> > - Page 5: Btw, why is "country" optional for identity_document but not
> > "eID" (Page 6)?
> Conceptually, it would be better to make country mandatory as well. But
there are cases in the wild where the IDP did not capture
> the country (because it was clear from the context back then - sometimes
20-30 yrs ago).
Ok, I see.
> > - And finally we are making heavy use of distributed claims in our
> > and I am having trouble in thinking how the special members
> > and _claim_sources (which also have usage in aggregated claims) would
> > along together with this spec. Maybe it's just one further example at
> > end that I am missing.
> Honestly, I haven’t thought about this because of lake of use cases. If
you can come up with text, I would happily add it.
Fine, I'll think about this.
More information about the Openid-specs-ab