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

Nick Roy nroy at internet2.edu
Fri Jul 20 14:34:54 UTC 2018


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 http://openid.net/connect/   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://www.linkedin.com/in/nynymike/
>> 
>>> 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
>>>    http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 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
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
>>> 
>>> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
>>>> 
>>>> 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:
>>> <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180720/00f40e94/attachment-0001.p7s>
>>> 
>>> ------------------------------
>>> 
>>> 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://bitbucket.org/openid/connect/issues/1032/rp-initiated-logout-proposal-for-client_id
>>>>> 
>>>>> 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
>>>> 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/43cba25d/attachment.html>
>>> 
>>> ------------------------------
>>> 
>>> Subject: Digest Footer
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> 
>>> 
>>> ------------------------------
>>> 
>>> End of Openid-specs-ab Digest, Vol 390, Issue 9
>>> ***********************************************
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
> 


More information about the Openid-specs-ab mailing list