[Openid-specs-risc] issuer conflict

Mike Jones Michael.Jones at microsoft.com
Thu Aug 3 19:19:03 UTC 2017


If you’re going to go with 3, at least use a claim name that’s specific to the task at hand – not a very generic one like “target” that would likely have other more general-purpose uses.  I’d suggest a claim name such as “risc_subject” for the data structure that you would define.

                                                                -- Mike

From: Phil Hunt [mailto:phil.hunt at oracle.com]
Sent: Thursday, August 3, 2017 10:55 AM
To: Mike Jones <Michael.Jones at microsoft.com>
Cc: Nat Sakimura <sakimura at gmail.com>; Marius Scurtescu <mscurtescu at google.com>; openid-specs-risc at lists.openid.net
Subject: Re: [Openid-specs-risc] issuer conflict

Mike/Nat

Option 2 is only simple if your world is exclusively connect and events only come from IDPs.

When you look at the broader cases, you can’t stop parsing just because you found a “sub” and “iss” at the top level. In the future parsers will have to check to see if “iss” is present in the event payload in order to infer the correct interpretation.  If they fail to check for an embedded “iss” they could end up making assumptions about the wrong subject.

This seems *very* complex in the sense that there are lots of unanticipated mistakes and assumptions that could be erroneously made in practice.

I *still* would like to see some consistency.  I like #3 because it affords flexibility between event types.  It would still allow “iss” and “sub” to be used within the nested object.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com<http://www.independentid.com>
phil.hunt at oracle.com<mailto:phil.hunt at oracle.com>

On Aug 3, 2017, at 10:41 AM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:

I agree with Nat here.  This seems like the simplest solution.

                                                       -- Mike

From: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Thursday, August 3, 2017 1:53 AM
To: Marius Scurtescu <mscurtescu at google.com<mailto:mscurtescu at google.com>>; openid-specs-risc at lists.openid.net<mailto:openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] issuer conflict

My preference: If all SET only supports a single iss/sub pair, then 1. If a SET can have events for multiple iss/sub pair, then 2.

2017年8月3日(木) 7:49 Marius Scurtescu <mscurtescu at google.com<mailto:mscurtescu at google.com>>:
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<https://tr.example.com/>",
  "aud": "https://rv.example.com/",
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked":
    {
      "iss": "https://example.com<https://example.com/>",
      "sub": "47635747",
    },
    "urn:ietf:params:risc:event:tokens-revoked":
    {
      "iss": "https://example.com<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<https://tr.example.com/>",
  "sub": "47635747",
  "aud": "https://rv.example.com/",
  "events": {
    "urn:ietf:params:risc:event:sessions-revoked":
    {
      "iss": "https://example.com<https://example.com/>",
    },
    "urn:ietf:params:risc:event:tokens-revoked":
    {
      "iss": "https://example.com<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<https://tr.example.com/>",
  "aud": "https://rv.example.com/",
  "events": {
    "iss": "https://example.com<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<https://tr.example.com/>",
  "aud": "https://rv.example.com/",
  "target": {
    "iss": "https://example.com<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<https://tr.example.com/>",
  "iss-sub": "https://example.com<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
_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-risc<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=4k0dpAmH57T_gD1fVCmltEYUmKxb4gb1hiM5ybc6jWg&s=xW2ScC8zZWSE739rBXF8kBvf2HyiRwKKJbgxuOXRr3s&e=>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
Openid-specs-risc mailing list
Openid-specs-risc at lists.openid.net<mailto:Openid-specs-risc at lists.openid.net>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=4k0dpAmH57T_gD1fVCmltEYUmKxb4gb1hiM5ybc6jWg&s=xW2ScC8zZWSE739rBXF8kBvf2HyiRwKKJbgxuOXRr3s&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170803/df10481f/attachment-0001.html>


More information about the Openid-specs-risc mailing list