[Openid-specs-risc] issuer conflict
Marius Scurtescu
mscurtescu at google.com
Fri Aug 4 17:09:35 UTC 2017
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-boun
>> ces 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.op
>> enid.net_mailman_listinfo_openid-2Dspecs-2Drisc&d=DwICAg&c=R
>> oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0F
>> kITSeGJxPEivzjWwlNKe4C_lLIGk&m=oELWrk4I8hITS0xtNBEzkxMNmGjd
>> HfFGkwNTJluxMQM&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=>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20170804/8fb47205/attachment-0001.html>
More information about the Openid-specs-risc
mailing list