[Openid-specs-ab] Please Either ABSTAIN or OBJECT fromtheFederation Spec Vote

John Bradley ve7jtb at ve7jtb.com
Fri Jul 20 17:29:13 UTC 2018


The reply to for the list is set to poster rather than list.   That is the way most of our lists are set up.

I guess that I have been trained over time to do reply all to get it to go to the list, and just don’t think about it any more.

Some of the lists are set to reply to list.

If people prefer to have replay as well as reply all go to the list I can change it.

I hope that explains it.

John B.

Sent from Mail for Windows 10

From: John Bradley
Sent: Friday, July 20, 2018 1:17 PM
To: Nick Roy
Cc: openid-specs-ab at lists.openid.net Ab
Subject: RE: [Openid-specs-ab] Please Either ABSTAIN or OBJECT fromtheFederation Spec Vote

Yes, that seems to be the case.   Strange.  I will have a look at the list settings, and see what has changed.

John

Sent from Mail for Windows 10

From: Nick Roy via Openid-specs-ab
Sent: Friday, July 20, 2018 11:19 AM
To: Phil Hunt
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from theFederation Spec Vote

As shown by both my and Phil's accidental replies off-list, there also
seems to be a list configuration issue which sets the reply-to address
as the address of the poster, rather than the address of the list.

Nick

On 7/20/18 9:17 AM, Phil Hunt wrote:
> 
> 
> Phil
> 
>> On Jul 20, 2018, at 8:16 AM, Phil Hunt <phil.hunt at oracle.com> wrote:
>>
>> I agree with Nick. The correct process (as i sort of understand it) and discussion was followed. 
>>
>> That said I have complained many times because of issues like this that the WG processes are not published and wg consensus is almost never called. 
>>
>> There is too much rush to implementation without a last call. 
>>
>> This is a serious problem the board must resolve.  
>>
>> Phil
>>
>>> On Jul 20, 2018, at 7:34 AM, Nick Roy via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
>>>
>>> This time to the list...
>>>
>>>> On Jul 20, 2018, at 8:30 AM, Nick Roy <nroy at internet2.edu> wrote:
>>>>
>>>> Mike, I personally provided feedback to Roland which he incorporated
>>>> into an updated draft over a year ago. The spec has been available in
>>>> draft form in github for something like two years.
>>>>
>>>> Nick
>>>>
>>>> On 7/20/18 8:16 AM, Mike Schwartz via Openid-specs-ab wrote:
>>>>>> And there's nothing that prevents that, just like there is nothing that
>>>>>> prevented me from working on HEART if I wanted to.
>>>>>>
>>>>>> Nick
>>>>>
>>>>> Actually, you're wrong. And I'm pretty active in the OpenID Connect 
>>>>> community... I don't think anyone would say otherwise.
>>>>>
>>>>> None of the design decisions on this spec were put to any kind of vote. 
>>>>> And as I pointed out previously, discussion was limited. It was a take 
>>>>> it or leave it design. Being presented at a conference is not the same 
>>>>> as getting a say in the process.
>>>>>
>>>>> It was a closed process, where Jones/Hedburg might or might take your 
>>>>> suggestions, depending on their whim. It has the veneer of openness, but 
>>>>> it's not actually open. It's a one party vote, take it or leave it.
>>>>>
>>>>> I can't start a spec and call it the "Connect AB Alternate Federation 
>>>>> Spec" and have it published here https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_connect_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=jglkfzh43veJDEsRH8sokGmpsmrh2afbdzoPw7Z-XH0&e=   So this 
>>>>> spec was given VERY special treatment, placement and promotion.
>>>>>
>>>>> Let's not call this an open process when it's not.
>>>>>
>>>>> - Mike
>>>>>
>>>>>
>>>>>
>>>>> ------------------------
>>>>> Michael Schwartz
>>>>> Gluu
>>>>> Founder / CEO
>>>>> mike at gluu.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_nynymike_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=hpgFrnPt9eP5DCbWWSkhzDGGgkCLxqsYB5OxNoFp674&e=
>>>>>
>>>>>> On 2018-07-20 06:17, openid-specs-ab-request at lists.openid.net wrote:
>>>>>> Send Openid-specs-ab mailing list submissions to
>>>>>>  openid-specs-ab at lists.openid.net
>>>>>>
>>>>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>>>>  https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
>>>>>> or, via email, send a message with subject or body 'help' to
>>>>>>  openid-specs-ab-request at lists.openid.net
>>>>>>
>>>>>> You can reach the person managing the list at
>>>>>>  openid-specs-ab-owner at lists.openid.net
>>>>>>
>>>>>> When replying, please edit your Subject line so it is more specific
>>>>>> than "Re: Contents of Openid-specs-ab digest..."
>>>>>>
>>>>>>
>>>>>> Today's Topics:
>>>>>>
>>>>>> 1. Re: Please Either ABSTAIN or OBJECT from the Federation Spec
>>>>>>    Vote (Nick Roy)
>>>>>> 2. Issue #1032: rp-initiated logout - proposal for client_id
>>>>>>    parameter (openid/connect) (Filip Skokan)
>>>>>> 3. Re: Issue #1032: rp-initiated logout - proposal for client_id
>>>>>>    parameter (openid/connect) (Vladimir Dzhuvinov)
>>>>>> 4. Re: Issue #1032: rp-initiated logout - proposal for client_id
>>>>>>    parameter (openid/connect) (Filip Skokan)
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> Message: 1
>>>>>> Date: Thu, 19 Jul 2018 18:05:45 +0000
>>>>>> From: Nick Roy <nroy at internet2.edu>
>>>>>> To: "openid-specs-ab at lists.openid.net"
>>>>>>  <openid-specs-ab at lists.openid.net>
>>>>>> Subject: Re: [Openid-specs-ab] Please Either ABSTAIN or OBJECT from
>>>>>>  the Federation Spec Vote
>>>>>> Message-ID:
>>>>>>  <CY4PR08MB35449C06D30AE97F5188DDFA83520 at CY4PR08MB3544.namprd08.prod.outlook.com>
>>>>>>
>>>>>> Content-Type: text/plain; charset="us-ascii"
>>>>>>
>>>>>> And there's nothing that prevents that, just like there is nothing that
>>>>>> prevented me from working on HEART if I wanted to.
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>>> On 7/19/18 10:43 AM, Mike Schwartz via Openid-specs-ab wrote:
>>>>>>> Nick,
>>>>>>>
>>>>>>> I thought you had a good idea to move federation to its own WG.
>>>>>>>
>>>>>>> So of course, I'm all for OpenID federations. And I'm also really
>>>>>>> interested in this proposed design. And I appreciate the work done by
>>>>>>> the current editors. It might be the best way. But I was never given a
>>>>>>> choice of A or B. I was just given a choice to approve A.
>>>>>>>
>>>>>>> I think the community should get a say in this design of this spec.
>>>>>>>
>>>>>>> - Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> it sounds like you aren't interested in working in an R&E working
>>>>>>>> group.
>>>>>>>> My understanding is that this WG will pursue R&E use cases for this
>>>>>>>> profile. Since R&E is one of the largest users of multilateral SAML
>>>>>>>> federation, I think exploring use of the OIDC Federation work in that
>>>>>>>> space is a great next step.
>>>>>>>>
>>>>>>>> Nick
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Message: 2
>>>>>> Date: Fri, 20 Jul 2018 08:10:50 +0000 (UTC)
>>>>>> From: "Filip Skokan" <issues-reply at bitbucket.org>
>>>>>> To: openid-specs-ab at lists.openid.net
>>>>>> Subject: [Openid-specs-ab] Issue #1032: rp-initiated logout - proposal
>>>>>>  for client_id parameter (openid/connect)
>>>>>> Message-ID:
>>>>>>  <20180720081050.39616.17365 at celery-worker-105.ash1.bb-inf.net>
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>
>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=
>>>>>>
>>>>>> Filip Skokan:
>>>>>>
>>>>>> I'd like to request that a parameter (optional or required?) client_id
>>>>>> is defined for rp-initiated logout request.
>>>>>>
>>>>>> rationale:
>>>>>>
>>>>>> Currently the id_token_hint is the only way of identifying the client
>>>>>> that's making the request. In scenarios where a client does not yet
>>>>>> have an id_token but makes a request to authenticate which fails (e.g.
>>>>>> due to being requested with essential sub claim through claims) the
>>>>>> next step will be to trigger an rp initiated logout with a registered
>>>>>> post_logout_redirect_uri but without an id_token_hint. This can be
>>>>>> problematic for OP deployments with a high number of clients as it is
>>>>>> not efficient or sometimes even not possible to iterate over all of
>>>>>> them to see if this post_logout_redirect_uri is whitelisted or not.
>>>>>> Hence the client_id parameter to make this lookup possible and
>>>>>> efficient.
>>>>>>
>>>>>> Further processing may be defined such as if both client_id and
>>>>>> id_token_hint are provided the audience of the id_token_hint must
>>>>>> include the client_id etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Message: 3
>>>>>> Date: Fri, 20 Jul 2018 14:01:29 +0300
>>>>>> From: Vladimir Dzhuvinov <vladimir at connect2id.com>
>>>>>> To: openid-specs-ab at lists.openid.net
>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout -
>>>>>>  proposal for client_id parameter (openid/connect)
>>>>>> Message-ID: <14898981-27c9-8a85-91c8-77c93a931278 at connect2id.com>
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>
>>>>>> Hi Filip,
>>>>>>
>>>>>> My concern is that relying on the client_id opens up post logout
>>>>>> redirection to potential misuse.
>>>>>>
>>>>>> IMO the OP shouldn't be picking any redirections if cannot be sure, to 
>>>>>> a
>>>>>> satisfactory degree, that it's the legitimate RP making the call.
>>>>>>
>>>>>> The ID token isn't really a substitute for proper RP authentication, 
>>>>>> but
>>>>>> it's some way towards that.
>>>>>>
>>>>>> A JWS request might help here, but it's probably too much to ask from 
>>>>>> RPs.
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>>
>>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=
>>>>>>>
>>>>>>> Filip Skokan:
>>>>>>>
>>>>>>> I'd like to request that a parameter (optional or required?) client_id 
>>>>>>> is defined for rp-initiated logout request.
>>>>>>>
>>>>>>> rationale:
>>>>>>>
>>>>>>> Currently the id_token_hint is the only way of identifying the client 
>>>>>>> that's making the request. In scenarios where a client does not yet 
>>>>>>> have an id_token but makes a request to authenticate which fails (e.g. 
>>>>>>> due to being requested with essential sub claim through claims) the 
>>>>>>> next step will be to trigger an rp initiated logout with a registered 
>>>>>>> post_logout_redirect_uri but without an id_token_hint. This can be 
>>>>>>> problematic for OP deployments with a high number of clients as it is 
>>>>>>> not efficient or sometimes even not possible to iterate over all of 
>>>>>>> them to see if this post_logout_redirect_uri is whitelisted or not. 
>>>>>>> Hence the client_id parameter to make this lookup possible and 
>>>>>>> efficient.
>>>>>>>
>>>>>>> Further processing may be defined such as if both client_id and 
>>>>>>> id_token_hint are provided the audience of the id_token_hint must 
>>>>>>> include the client_id etc.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------- next part --------------
>>>>>> A non-text attachment was scrubbed...
>>>>>> Name: smime.p7s
>>>>>> Type: application/pkcs7-signature
>>>>>> Size: 4002 bytes
>>>>>> Desc: S/MIME Cryptographic Signature
>>>>>> URL:
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_00f40e94_attachment-2D0001.p7s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=eTHo7f8tNiakUT3d8PkF8AQgSq44lpjr4_2Y7S8skp4&e=>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Message: 4
>>>>>> Date: Fri, 20 Jul 2018 13:16:52 +0200
>>>>>> From: Filip Skokan <panva.ip at gmail.com>
>>>>>> To: Vladimir Dzhuvinov <vladimir at connect2id.com>
>>>>>> Cc: "openid-specs-ab at lists.openid.net Ab"
>>>>>>  <openid-specs-ab at lists.openid.net>
>>>>>> Subject: Re: [Openid-specs-ab] Issue #1032: rp-initiated logout -
>>>>>>  proposal for client_id parameter (openid/connect)
>>>>>> Message-ID:
>>>>>>  <CALAqi_8w2uvCd9R39YQpL-QxT7srCTvgpQvqkGXnrfo80owEFw at mail.gmail.com>
>>>>>> Content-Type: text/plain; charset="utf-8"
>>>>>>
>>>>>> Hello Vladimir,
>>>>>>
>>>>>> The OP is advised to render a prompt for the end-user in those cases 
>>>>>> where
>>>>>> post_logout_redirect_uri is not provided. And there's no mention of
>>>>>> ignoring the post_logout_redirect_uri param if id_token_hint is 
>>>>>> missing.
>>>>>>
>>>>>> Currently:
>>>>>>
>>>>>>> post_logout_redirect_uri
>>>>>>> OPTIONAL. URL to which the RP is requesting that the End-User's User 
>>>>>>> Agent
>>>>>>> be redirected after a logout has been performed. The value MUST have 
>>>>>>> been
>>>>>>> previously registered with the OP, either using the
>>>>>>> post_logout_redirect_uris Registration parameter or via another 
>>>>>>> mechanism.
>>>>>>> If supplied, the OP SHOULD honor this request following the logout.
>>>>>>
>>>>>>
>>>>>> No mention of ignoring the value if id_token_hint is not provided.
>>>>>>
>>>>>> and under security considerations, the advise to prompt.
>>>>>>
>>>>>> The id_token_hint parameter to a logout request can be used to 
>>>>>> determine
>>>>>>> which RP initiated the logout request. Logout requests without a valid
>>>>>>> id_token_hint value are a potential means of denial of service; 
>>>>>>> therefore,
>>>>>>> OPs may want to require explicit user confirmation before acting upon 
>>>>>>> them.
>>>>>>
>>>>>>
>>>>>> Supplying a client_id does not change a potential extra OP policy that
>>>>>> id_token_hint must be provided if it choses to do so, it simply makes
>>>>>> post_logout_redirect_uri lookup possible in cases where loading all 
>>>>>> uris or
>>>>>> clients into memory is not possible/is inefficient or can't query for 
>>>>>> all
>>>>>> valid uris for the same reasons.
>>>>>>
>>>>>> Best,
>>>>>> *Filip*
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 20, 2018 at 1:01 PM Vladimir Dzhuvinov via Openid-specs-ab 
>>>>>> <
>>>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>>>
>>>>>>> Hi Filip,
>>>>>>>
>>>>>>> My concern is that relying on the client_id opens up post logout
>>>>>>> redirection to potential misuse.
>>>>>>>
>>>>>>> IMO the OP shouldn't be picking any redirections if cannot be sure, to 
>>>>>>> a
>>>>>>> satisfactory degree, that it's the legitimate RP making the call.
>>>>>>>
>>>>>>> The ID token isn't really a substitute for proper RP authentication, 
>>>>>>> but
>>>>>>> it's some way towards that.
>>>>>>>
>>>>>>> A JWS request might help here, but it's probably too much to ask from 
>>>>>>> RPs.
>>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>>
>>>>>>>> On 20/07/18 11:10, Filip Skokan via Openid-specs-ab wrote:
>>>>>>>> New issue 1032: rp-initiated logout - proposal for client_id parameter
>>>>>>>>
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1032_rp-2Dinitiated-2Dlogout-2Dproposal-2Dfor-2Dclient-5Fid&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=XPovg09GXpcxWGyelD8zKNCUzJP71dmPh3bNGNK7k5w&e=
>>>>>>>>
>>>>>>>> Filip Skokan:
>>>>>>>>
>>>>>>>> I'd like to request that a parameter (optional or required?) client_id
>>>>>>> is defined for rp-initiated logout request.
>>>>>>>>
>>>>>>>> rationale:
>>>>>>>>
>>>>>>>> Currently the id_token_hint is the only way of identifying the client
>>>>>>> that's making the request. In scenarios where a client does not yet 
>>>>>>> have an
>>>>>>> id_token but makes a request to authenticate which fails (e.g. due to 
>>>>>>> being
>>>>>>> requested with essential sub claim through claims) the next step will 
>>>>>>> be to
>>>>>>> trigger an rp initiated logout with a registered 
>>>>>>> post_logout_redirect_uri
>>>>>>> but without an id_token_hint. This can be problematic for OP 
>>>>>>> deployments
>>>>>>> with a high number of clients as it is not efficient or sometimes even 
>>>>>>> not
>>>>>>> possible to iterate over all of them to see if this
>>>>>>> post_logout_redirect_uri is whitelisted or not. Hence the client_id
>>>>>>> parameter to make this lookup possible and efficient.
>>>>>>>>
>>>>>>>> Further processing may be defined such as if both client_id and
>>>>>>> id_token_hint are provided the audience of the id_token_hint must 
>>>>>>> include
>>>>>>> the client_id etc.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Openid-specs-ab mailing list
>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
>>>>>>>
>>>>>> -------------- next part --------------
>>>>>> An HTML attachment was scrubbed...
>>>>>> URL:
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dab_attachments_20180720_43cba25d_attachment.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=KmCCQjnkztIL-CzFEhohJrsvdGwCZtWRDGDfwFTOOTs&e=>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Subject: Digest Footer
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> End of Openid-specs-ab Digest, Vol 390, Issue 9
>>>>>> ***********************************************
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
>>>>>
>>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qJYRDsHBZhYt-b1obYtxq0fcLFu53TKBfl2_Hw2Gajw&s=vqMu4wpIOPufViYMGvzTtZtsynYxmLnmUHJCL88jWLY&e=
> 
> 
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180720/9ddd66e2/attachment-0001.html>


More information about the Openid-specs-ab mailing list