[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Thu Aug 3 22:23:45 UTC 2017


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

> Each alias might have a different issuer/scope.
>

Maybe, but let's get concrete since I believe we have to define each alias.
What else than iss+sub, email and phone_number?


> Email is also tricky, as foreign emails are often used as the username.
>

Right, and I think that's irrelevant in this case. If not, then why not?


>
> That email address used as a name may or may not be validated.
>

Good point, and again not sure how is this relevant to SET. The add/remove
APIs most likely will have to also provide the "email_verified" claim along
with "email", but that's a different draft.


>
> I still have a test Facebook account with a email as the login name that
> has never been validated after nearly two years.
>

Right, it is a common case. Also, if the email was validated 8 years ago,
what value does that validation still have?


>
> So is talking about “self-issued at hotmail,.com” scope Facebook the same as
> sef-issued.com scope google vs scope Microsoft the same or different?
>

> Are some usernames with issuers and only the MS scoped one a real email?
>
> In general you have a identifier string of some sort scoped to a
> responsible authority.
> I don’t really care if you want to have
> {“val”: “self-issued at hotmail,.com”,  “scope”: “Facebook” , “type”:
> “email”}
>
> Or create specific claims that combine type and val.
>

Not sure I completely follow. What does "scope Facebook" mean with regards
to  self-issued at hotmail,.com? Microsoft is authoritative over that email
address, and how does one discover that is a different question.

If Google is sending a RISC event to Facebook and the subject is
"email=self-issued at hotmail,.com" then scope=Facebook I think is implied
(the fact that Facebook knows the user as self-issued at hotmail,.com). How
would an explicit scope help here? Do you have a use case in mind?


> I suspect that having it be a object will allow for cleanly adding other
> meta-data later.
>

I think everyone agrees it should be an object. You suggested that the
value could be an array, I am not sure I understand the need for that.


>
> I do think that it is a new claim separate from the existing sub, and
> needs the context of who is the responsible authority for the identifier or
> it will get very messy.
>

Right, but I think who is responsible for the identifier (scope?) is clear
by the context (transmitter and receiver).


>
> John B.
>
>
> On Aug 3, 2017, at 4:36 PM, Marius Scurtescu <mscurtescu at google.com>
> wrote:
>
> 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/8100552e17554422b6207
>>> b7bd7a9bc76”
>>> }
>>>
>>> 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/3e6c3d41/attachment-0001.html>


More information about the Openid-specs-risc mailing list