[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Thu Aug 3 20:36:18 UTC 2017


On Thu, Aug 3, 2017 at 12:02 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Alias or aka
>
> I am issuer foo and the subject is bar in my context.   I also know them
> as “self-issued at hotmail.com” in the context of Facebook and +15555551235
> in the context of phone number.
>
> That leaves the current definitions of sub and its unchanged.
>

All the different ways the identity can be referred to must be defined by
the profile. Right?

For the RISC profile I had in mind:
- iss+sub
- email
- phone_number

Obviously this is inspired by OpenID Connect, the same claims can be
present in an Id Token.

If the above makes sense, then not sure if an array is needed.



> John B.
>
> On Aug 3, 2017, at 2:57 PM, Phil Hunt (IDM) <phil.hunt at oracle.com> wrote:
>
> Agreed.
>
> Phil
>
> On Aug 3, 2017, at 11:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
> Identity or whatever it is called may actually want to be an array, as
> there might be multiple synonyms.
>
> That is why I was thinking of it more as an alias of sub + iss.
>
>
> On Aug 3, 2017, at 1:49 PM, Marius Scurtescu <mscurtescu at google.com>
> wrote:
>
> On Thu, Aug 3, 2017 at 10:39 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>
>> yes.  Instead of using “sub”  you might define an attribute “identity”
>> and it could be used as follows:
>>
>> “identity”:{
>>   “typ”:”oidc”,
>>   “sub”:”8100552e17554422b6207b7bd7a9bc76”,
>>   “iss”:”myidp.example.com"
>> }
>>
>> Or:
>>
>> “identity”:{
>>   “typ”:”scim”,
>>   “$ref”:”https://scim.example.com/Users/8100552e17554422b6207b7bd7a9bc76
>>>> }
>>
>> Or
>>
>> (not sure these are the right claims, but you might include some claims
>> from MODRNA like carrier identifiers if they are available)
>> “identity”:{
>>   “typ”:”phone”,
>>   “telephoneNumber”:”+16041234567”
>>   “carrier”: <somevalue>
>> }
>>
>> “identity”:{
>>   “typ”:”emails”,
>>   “mail”:”john.doe at example.com>> }
>>
>> Note “identity” could be used at the top level or embedded in events
>> payload.  Top level if there is need to have multiple event types are
>> expressed at once.  Or, if part of the core spec to provide a consistent
>> pattern for identifiers and to establish a registry of identifier types.
>> Regardless at the top level, then “identity” would have to be registered as
>> a JWT claim.
>>
>
> This is a separate discussion we should have, I was proposing something
> different here, but I was trying to focus on the issuer conflict first.
>
> That being said, I don't see why a typ claim is needed here. We can use
> the exact same claims as in an Id Token. SCIM needs a different profile
> than RISC.
>
> Your examples from above using Id Token claims (minus the SCIM example):
>
> “identity”:{
>   “sub”:”8100552e17554422b6207b7bd7a9bc76”,
>   “iss”:”myidp.example.com"
> }
>
> “identity”:{
>   “phone_number”:”+16041234567”
> }
>
> “identity”:{
>   “email”:”john.doe at example.com> }
>
>
>> Phil
>>
>> Oracle Corporation, Identity Cloud Services Architect & Standards
>> @independentid
>> www.independentid.com
>> phil.hunt at oracle.com
>>
>> On Aug 3, 2017, at 10:28 AM, Marius Scurtescu <mscurtescu at google.com>
>> wrote:
>>
>> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dcore-2D1-5F0.html-23IndividualClaimsRequests&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0XvWuopUa1rUzdTHlWsUVZI7PePtDaGu3VrMUlwE2yU&s=VzfByRviJEJHNZfefEzIWK8KsuPhKsf_RXi6eOTxbeI&e=>
>>> .
>>>
>>> However in responses sub is defined in
>>> https://tools.ietf.org/html/rfc7519#section-4.1.2
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0XvWuopUa1rUzdTHlWsUVZI7PePtDaGu3VrMUlwE2yU&s=5GZBJpUnQsgSTinzQRg5GLOPDs6YuqtEr_PEMy9JsMQ&e=>
>>>   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.op
>>> enid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=R
>>> oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0F
>>> kITSeGJxPEivzjWwlNKe4C_lLIGk&m=oELWrk4I8hITS0xtNBEzkxMNmGjdH
>>> fFGkwNTJluxMQM&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
>>> <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=0XvWuopUa1rUzdTHlWsUVZI7PePtDaGu3VrMUlwE2yU&s=EIvVFfL8djzqG2zMxSY4EPjMuBglQoE0xKzdgiOiOK8&e=>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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=0XvWuopUa1rUzdTHlWsUVZI7PePtDaGu3VrMUlwE2yU&s=EIvVFfL8djzqG2zMxSY4EPjMuBglQoE0xKzdgiOiOK8&e=>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170803/52ca2cd4/attachment-0001.html>


More information about the Openid-specs-risc mailing list