[Openid-specs-risc] issuer conflict

Phil Hunt (IDM) phil.hunt at oracle.com
Fri Aug 4 22:28:21 UTC 2017


Ok if you haven't already confirmed please let me know if you would like to attend and I will send an invite. 

So far I have Marius, John, and Mike. 

Phil

> On Aug 4, 2017, at 2:50 PM, Marius Scurtescu <mscurtescu at google.com> wrote:
> 
> I might be able to manage the gotomeeting seesion, but with Adam away it is risky.
> 
> Phil, can you please setup a zoom session for Tuesday at 9 am?
> 
> Marius
> 
>> On Fri, Aug 4, 2017 at 11:03 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>> If gotomeeting doesn’t have a slot (e.g. due to igov), I can volunteer my zoom line.
>> 
>> Phil
>> 
>> Oracle Corporation, Identity Cloud Services Architect & Standards
>> @independentid
>> www.independentid.com
>> phil.hunt at oracle.com
>> 
>>> On Aug 4, 2017, at 10:47 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>> 
>>> I can do that.  Can someone please send the gotomeeting link we’ll be using in a calendar message?
>>>  
>>>                                                                 -- Mike
>>>  
>>> From: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] On Behalf Of Phil Hunt
>>> Sent: Friday, August 4, 2017 10:26 AM
>>> To: Marius Scurtescu <mscurtescu at google.com>
>>> Cc: openid-specs-risc at lists.openid.net
>>> Subject: Re: [Openid-specs-risc] issuer conflict
>>>  
>>> WFM
>>>  
>>> Phil
>>>  
>>> Oracle Corporation, Identity Cloud Services Architect & Standards
>>> @independentid
>>> www.independentid.com
>>> phil.hunt at oracle.com
>>>  
>>> On Aug 4, 2017, at 10:09 AM, Marius Scurtescu <mscurtescu at google.com> wrote:
>>>  
>>> What about 9 am on Tuesday?
>>> 
>>> Marius
>>>  
>>> On Fri, Aug 4, 2017 at 10:02 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> 3pm Monday before the Connect call is open.   
>>>  
>>> I can only join for 30min at 9:30 Tuesday because of another call I have at 10am.
>>>  
>>> John B.
>>>  
>>> On Aug 4, 2017, at 12:51 PM, Marius Scurtescu <mscurtescu at google.com> wrote:
>>>  
>>> Yes, we need a call. We have the regular call scheduled for Monday morning at 9:30 AM PST, but unfortunately I will be traveling at that time. Adam is on vacation next week.
>>>  
>>> Would it be OK to shift the Monday call either to Monday afternoon 3 pm, or Tuesday morning 9:30 am?
>>> 
>>> Marius
>>>  
>>> On Thu, Aug 3, 2017 at 9:31 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>> I agree that a call would be productive at this point.
>>>  
>>>                                                        Best wishes,
>>>                                                        -- Mike
>>>  
>>> From: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] On Behalf Of Phil Hunt (IDM)
>>> Sent: Thursday, August 3, 2017 7:19 PM
>>> To: Marius Scurtescu <mscurtescu at google.com>
>>> Cc: openid-specs-risc at lists.openid.net
>>> Subject: Re: [Openid-specs-risc] issuer conflict
>>>  
>>> I think we need to do a call and walk through the bootstrap cases for implicit federation vs explicit. 
>>>  
>>> Depending on how things start, how asserting parties know the user is very different. 
>>> 
>>> Phil
>>> 
>>> On Aug 3, 2017, at 6:59 PM, Marius Scurtescu <mscurtescu at google.com> wrote:
>>> 
>>> On Thu, Aug 3, 2017 at 4:00 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> I suggested an array if there are multiple values that want to be published for some reason.
>>> Otherwise you limit yourself to one scope for all the aliases.
>>>  
>>> Perhaps it is more of a SET issue than RISC but this all started with the proposition that sub might not be scoped to the issuer in cases where a RP is sending to a IdP. 
>>>  
>>> So when Facebook sends to Google it would not need to scope its own identifiers.   But if it is talking about a account that google has identified as having the email address self-issued at hotmail.com then it would scope it.
>>>  
>>> RISC events sent by Facebook to Google should always use an identifier scoped to Google. Assuming Facebook is an OAuth 2 client and Google the IdP. Facebook could know the Google issued sub or the email address associated with the account (which could be a non-Google managed email). Identifiers issued by Facebook are meaningless to Google. If Facebook is the IdP and Google the RP, then Facebook issued identifiers would work.
>>>  
>>> If you are aware of a use case when the identifier needs to be explicitly scoped then let's add it to:
>>> https://tools.ietf.org/html/draft-scurtescu-secevent-risc-use-cases
>>>  
>>> Currently we are not tracking any use case like that.
>>>  
>>>  
>>>  
>>> Email may not be the best example because we mistakenly believe that addresses uniquely point to one individual. 
>>> They might but if it is not a email and just an account identifier then knowing who’s it is important.
>>>  
>>> Confusing of account identifiers and email addresses is a horse that has left the barn.
>>>  
>>> If the subject were just account numbers that could easily collide then scoping has a clearer value.
>>>  
>>> An IdP could use account identifiers, or numbers, but these would be expressed as the sub claim and sub is always scoped to the IdP issuer. No other scoping is needed IMO.
>>>  
>>>  
>>>  
>>> Phone numbers have similar issues.  They have a higher turn over and reuse than email.
>>>  
>>> If the sub email phone etc is scoped to the issuer use the top level elements.
>>>  
>>> In cases where it is different ave a alias object that makes the scoping explicit.
>>>  
>>> I think email and phone is always global and does not need scoping. If not, then we need to clarify this.
>>>  
>>> sub is scoped by iss.
>>>  
>>>  
>>>  
>>> You might have both in a SET if the sender wants to expose its sub and also explicitly include a alias that the receiver understands like a phone number.
>>>  
>>> Yes, both can be present.
>>>  
>>>  
>>> I think we are saying the same thing.
>>>  
>>> Here is proposal 3 again:
>>>  
>>> Top level claims when there is no iss conflict:
>>>  
>>> {
>>>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>>>   "iat": 1458496025,
>>>   "iss": "https://tr.example.com",
>>>   "aud": "https://rv.example.com/",
>>>   "sub": "47635747",
>>>   "email": "user at example.com",
>>>   "phone_number": "123-555-9876,
>>>   "events": {
>>>     "urn:ietf:params:risc:event:sessions-revoked": {},
>>>     "urn:ietf:params:risc:event:tokens-revoked": {}
>>>   }
>>> }
>>>  
>>> And nested object when there is an iss conflict:
>>>  
>>> {
>>>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>>>   "iat": 1458496025,
>>>   "iss": "https://tr.example.com",
>>>   "aud": "https://rv.example.com/",
>>>   "risc_subject": {
>>>     "iss": "https://example.com",
>>>     "sub": "47635747",
>>>     "email": "user at example.com",
>>>     "phone_number": "123-555-9876,
>>>   },
>>>   "events": {
>>>     "urn:ietf:params:risc:event:sessions-revoked": {},
>>>     "urn:ietf:params:risc:event:tokens-revoked": {}
>>>   }
>>> }
>>>  
>>> sub, email and phone_number form a set of claims that point to a person, at least one of these claims must be preset.
>>>  
>>> Sounds good?
>>>  
>>>  
>>>  
>>> John B.
>>>  
>>>  
>>> On Aug 3, 2017, at 6:23 PM, Marius Scurtescu <mscurtescu at google.com> wrote:
>>>  
>>> 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/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.
>>>  
>>> 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
>>> -- 
>>> 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
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> _______________________________________________
>>> 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
>>> 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=ar-V7quwUKHP0_EoDjVLj3sD47XneddlJAI0NPcWsGQ&s=cOt0Kk2JSbsPiJXN9s1-CLrTq7BRslQsVUHyvCpGvhY&e=
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170804/9e5bcce2/attachment-0001.html>


More information about the Openid-specs-risc mailing list