[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Thu Aug 3 19:55:45 UTC 2017


"risc_subject" sounds good to me.

Marius

On Thu, Aug 3, 2017 at 12:19 PM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

> 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
>
> phil.hunt at oracle.com
>
>
>
> On Aug 3, 2017, at 10:41 AM, Mike Jones <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 <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>; openi
> d-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>:
>
> 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
>
> _______________________________________________
> Openid-specs-risc mailing list
> 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
> 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=xW2ScC8zZWSE739rBXF8kBvf2HyiRw
> KKJbgxuOXRr3s&e=
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170803/ba955467/attachment-0001.html>


More information about the Openid-specs-risc mailing list