[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Thu Aug 3 18:06:15 UTC 2017


On Thu, Aug 3, 2017 at 10:59 AM, Phil Hunt <phil.hunt at oracle.com> wrote:

> Marius,
>
> Agreed with your concerns.  I wasn’t clear on why it was useful.
>
> I suspect in some RISC events, there may be a need to issue the same event
> for both implicit and explicitly federated users.  Thus, in the event, you
> need to flag the type of user.
>

Right, but then the event would be sent to two different receivers and the
actual SET can be custom for each one (the explicit receiver will see a
"sub" claim while the implicit receiver will see only an "email" claim). I
don't think typ is needed for this case.


> “typ” is also useful if we want a registry so that we don’t end up with
> different event profiles using different attributes to reference the same
> thing.  E.g. we might want to avoid email being specified with different
> attributes for the same thing: “mail”, “email”, “rfc822”.
>

Since we cannot mix events from different profiles in the same SET (do we
agree on that?), I don't think we need a registry to make claims consistent
across profiles.


>
>
> Phil
>
> Oracle Corporation, Identity Cloud Services Architect & Standards
> @independentid
> www.independentid.com
> phil.hunt at oracle.com
>
> On Aug 3, 2017, at 10:49 AM, 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=8DgoyHO0bkvBmE7iO1lCEHlfY6qf43cH7pWx3Ekpiow&s=uBPtLJ_OeovXu0GNe8dSZcmX3LYoMrlu_N5HRH_5MQY&e=>
>> 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/dbd0a810/attachment-0001.html>


More information about the Openid-specs-risc mailing list