[Openid-specs-ab] Please Either ABSTAIN or OBJECT from the Federation Spec Vote

Phil Hunt phil.hunt at oracle.com
Fri Jul 20 15:17:26 UTC 2018 


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=

More information about the Openid-specs-ab mailing list