[openid-specs-rande] contacts claim and metadata extension

[Davide Vaghetti]

Hi,

today I had a very interesting call with Roland Hedberg and Mischa Salle
to discuss some open issues on the current OpenID Connect Federation
specification.

One of the issue discussed was about the `contacts` claim. Being it a
simple list, it does not allow to specify the contact type, so it can't
be used for example to communicate at one time a technical contact and a
security one. Now, in the R&E world we do have such a need, in fact in
the the Sirtfi framework [1] that establish, among other things, exactly
that: you need to handle security incidents through a specialized
security contact (possibly the email of your trustworthy CERT/CSIRT).

In terms of metadata Sirtfi has also another requirement: entities that
participate to the framework SHOULD advertise it through the assurance
entity attribute.

So, this is one of the use case that can be used as fuel for the
specification on the "Entity metadata extension for OpenID Connect".

My personal idea was to define a claim with a JSON object as a value.
The specific structure of such an object should be defined by a separate
specification. Not much different than what we are doing in today's R&E
identity federations.

So, in the case of an OP that participates to Sirtfi we would have
something like:

{
  "issuer":
    "https://server.example.com",
   "authorization_endpoint":
    "https://server.example.com/",

[..]

  "metadata_ext": {
    "type": "not-sure",
    "ref_uri": "https://refeds.org/sirtfi",
    "contact": {
      "email": ["cert at example.com"],
      "tel": [
        "BETTER-CALL-SAUL",
        "BIG-TROUBLE-IN-LITTLE-CHINA"
      ]
    }
  }
}

The `metadata_ext` claim, the `ref_uri` and the `type` claims inside are
the part in common with every metadata extensions, while the value of
`ref_uri` and the `contact` claim would be the Sirtfi specific part. It
could even be specified as a json-schema [2], so the validation could be
automated.

Another way to model Sirtfi is, on the contrary, to create a set of flat
claims to be added to an entity metadata, plus probably a generic claim
that would point to the Sirtfi specification reference uri
(`extension_ref_uri` for example).

Comments are welcome!

Cheers,
Davide

[1] https://refeds.org/sirtfi
[2] http://json-schema.org

-- 
Davide Vaghetti
Consortium GARR
Tel: +390502213158
Mobile: +393357779542
Skype: daserzw


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-rande/attachments/20181214/7d606fb5/attachment.p7s>