[Openid-specs-risc] issuer conflict

Marius Scurtescu mscurtescu at google.com
Fri Aug 4 16:51:04 UTC 2017


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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dscurtescu-2Dsecevent-2Drisc-2Duse-2Dcases&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g-XR90LJbGJs22ZRyHyrQImdiSKuOUnSx-uMihcBj0E&s=OX-mKgdgZCEmFXFwEXGLt-kVgWVuGo1ALdObEvqys0U&e=>
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__sef-2Dissued.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g-XR90LJbGJs22ZRyHyrQImdiSKuOUnSx-uMihcBj0E&s=dtZNC7Ug_OjhPH2dXU2AD0ubqcbveLV8e91TJqDzyRM&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=g-XR90LJbGJs22ZRyHyrQImdiSKuOUnSx-uMihcBj0E&s=EvUUqTsPqYyUuG705IQ1fE0g8wpPX5VG6xbOnpVHvsQ&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.
> 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
> <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/20170804/d72eab28/attachment-0001.html>


More information about the Openid-specs-risc mailing list