[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Thu Aug 3 17:28:30 UTC 2017


On Thu, Aug 3, 2017 at 9:42 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I guess in principal sub could be a dictionary with a val and other meta
> data like a optional issuer.
>
> We do that with sub in Connect claims requests
> <http://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests>
> .
>
> However in responses sub is defined in
> https://tools.ietf.org/html/rfc7519#section-4.1.2  as a string.
>
> One option might be to have a new claim.  sub-d that is a dictionary that
> you could use when you need a more complicated sub with a
> SubjectNameIdFormat and scope.   How could that go wrong:)
>

That is option 3, right?


>
> John B.
>
>
>
> On Aug 3, 2017, at 12:19 PM, Phil Hunt (IDM) <phil.hunt at oracle.com> wrote:
>
> Lets not forget that we also have cases where subject is identified by
> email or telephone or other identifier (implicit fed cases).
>
> Risc needs to have a subject type attribute to inform parsers how to
> identify the subject. The next question whether sub gets re-used as a
> general purpose attribute or whether specific attributes are used for each
> type (email, telephone).
>
> In solving this broader requirement the sub/iss problem may also be
> resolved.
>
> Phil
>
> On Aug 3, 2017, at 1:52 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> 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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=oELWrk4I8hITS0xtNBEzkxMNmGjdHfFGkwNTJluxMQM&s=WH0oHORcbz6GzolvV9301ap4nCL-qYRmD7wWIWPJnL8&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=
> oELWrk4I8hITS0xtNBEzkxMNmGjdHfFGkwNTJluxMQM&s=WH0oHORcbz6GzolvV9301ap4nCL-
> qYRmD7wWIWPJnL8&e=
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170803/2035370a/attachment.html>


More information about the Openid-specs-risc mailing list