[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Wed Aug 2 22:48:41 UTC 2017


Each SET profile must define or clarify several aspects of the specs. For
RISC most of these must only be only specified (like key resolution), but
there is at least one issue for which we don't have an agreed on solution.

In some use cases the issuer of the SET is different from the issuer of the
subject identifier, and at least in those cases there cannot be only one
top level "iss" claim.

Here are the proposals I am aware of to solve this issue:

1. Move iss+sub to the event level. The drawback of this approach is
redundancy when multiple events are present in the SET.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://tr.example.com",
  "aud": "https://rv.example.com/",
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked":
    {
      "iss": "https://example.com",
      "sub": "47635747",
    },
    "urn:ietf:params:risc:event:tokens-revoked":
    {
      "iss": "https://example.com",
      "sub": "47635747",
    }
  }
}


1.1 Move only the subject "iss" to the event level and leave "sub" at the
top level (next to the SET "iss"). I find this solution very confusing.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://tr.example.com",
  "sub": "47635747",
  "aud": "https://rv.example.com/",
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked":
    {
      "iss": "https://example.com",
    },
    "urn:ietf:params:risc:event:tokens-revoked":
    {
      "iss": "https://example.com",
    }
  }
}


2. Move iss+sub immediately under the "events" claim. No redundancy in this
case.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://tr.example.com",
  "aud": "https://rv.example.com/",
  "events": {
    "iss": "https://example.com",
    "sub": "47635747",
    "urn:ietf:params:risc:event:sessions-revoked": {},
    "urn:ietf:params:risc:event:tokens-revoked": {}
  }
}


3. Move iss+sub to a new nested claim.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://tr.example.com",
  "aud": "https://rv.example.com/",
  "target": {
    "iss": "https://example.com",
    "sub": "47635747",
  },
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked": {},
    "urn:ietf:params:risc:event:tokens-revoked": {}
  }
}


4. Define a new top level issuer claim either for the SET or for the
subject.

{
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "iat": 1458496025,
  "iss": "https://tr.example.com",
  "iss-sub": "https://example.com",
  "sub": "47635747",
  "aud": "https://rv.example.com/",
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked": {},
    "urn:ietf:params:risc:event:tokens-revoked": {}
  }
}


An open question is if this new iss+sub solution should be always required
or if a top level iss+sub should also be allowed (when there is no
conflict). I vote for having only one way for simplicity.

Once we decide on a solution we can start working on the RISC profile draft.

Thoughts?

Marius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170802/7639cc96/attachment.html>


More information about the Openid-specs-risc mailing list