[Openid-specs-ab] OpenID AB/Connect WG Call Note (2018-08-30)

n-sakimura n-sakimura at nri.co.jp
Thu Aug 30 15:39:40 UTC 2018


===================================================
OpenID AB/Connect WG Call Note (2018-08-30)
===================================================
Date: 2018-08-30 14:00 UTC

Location: GoToMeeting https://global.gotomeeting.com/join/181372694

Agenda
-----------
1.   Roll Call
2.   Commonalities and Differences Report on Fed Specs (Andreas/Roland)
3.   Issues
3.1.   #1046 - Core 3.1.2.1. - id_token_hint (Torsten)
3.2.   #1047 - session_state - upon authentication failure? (Filip)
3.3.   #1048 - Correct way to return errors (fragment vs query) in hybrid flow is unclear (Joseph)
3.4.   #1033 - RP-initiated logout: require valid id_token_hint to take action on post_logout_redirect_uri (Filip)
4.   AOB
4.1.   Topics for the next call
4.2.   OIX Meeting on 10 and 11

The meeting was called to order at 14:05 UTC.

1. Roll Call
=============
* Present: Nat, Andreas, Brian, Chris Phillips, Filip, George, Henrik, Roland, Sarah, Torsten, Bjorn, Brian, Rich, Joseph

2. Commonalities and Differences Report on Fed Specs (Andreas/Roland)
=====================================================================

Commonalities

1. Both are based on a trust chain.

    * Roland: Nested objects. Allows by value. --> can switch to list.
    * Andreas: List. Only by references.

2. Both use Flattening.

3. Differences

    * Roland: 3.1 OIDC standard dynamic registration
    * Andreas: 3.2 No registration: Implicit use of asymmetric key/webfinger

     RP just sends authorization req.
     Client_id = url so OP can use webfinger.
     Registration is to a common trust root.

It seems to be able to come up with a draft that has a common approach on 1, 2 and options to choose either 3.1 or 3.2.

Chris also pointed out that Multi-lateral trust needs to be addressed explicitly.
Everybody agreed that current "implicit" assumption on it should be made explicit.

Nat asked if there is a way to have two federations interoperate at a later day if they have chosen 3.1 and 3.2 respectively. This is a valid use-case and needs more consideration.

There are F2F opportunity at

* TecEx: https://meetings.internet2.edu/2018-technology-exchange/
* IIW

Roland, Andreas and Chris are going to have more conversations and
should be able to come up with a report in a few weeks.

3. Issues
============

#1046 - Core 3.1.2.1. - id_token_hint (Torsten)
-------------------------------------------------
* #1046: https://bitbucket.org/openid/connect/issues/1046/core-3121-id_token_hint

Add non-normative text to say that login_hint is any string that
helps RP to identify who the user is.

Norway, login_hint is used to signal the issuer.

George will come up with a proposed. text.

#1047 - session_state - upon authentication failure? (Filip)
-------------------------------------------------------------
* #1047 - https://bitbucket.org/openid/connect/issues/1047/

Text scattered all over so should be collected at one place.
Filip will produce a suggested text.

#1048 - Correct way to return errors (fragment vs query) in hybrid flow is unclear (Joseph)
--------------------------------------------------------------------------------------------
* #1048 - https://bitbucket.org/openid/connect/issues/1048/

It should be returned in the fragment as the certification suite at the end of last year was OK with returning it in the query string. This behaviour is now fixed and the error should be returned in the fragment.
People agreed that the current text is not clear while our intention is clear.

Text should be clarified.

Assign it to Mike.

#1033 - RP-initiated logout: require valid id_token_hint to take action on post_logout_redirect_uri (Filip)
-------------------------------------------------------------------------------------------------------------
* #1048 - https://bitbucket.org/openid/connect/issues/1033/

This ticket is related to #1032.

It is clear that there needs to be a mechanism to validate that it is safe to do a redirect.
Are there other mechanisms that do not require login_hint?

* Session ID OR
* Session ID + Client ID.
    * #1032 Post logout URI + Client ID.

DOS attack possibilities etc. need to be considered as well.
Time has run out while we were discussing this issue.
It needs to be continued on the ticket.

4. AOB
==============

4.1 Topics for the next call
-----------------------------
1. Safari IPT2 and implicit flow
2. Native SSO spec.
3. Issue #1029

4.2 OIX Meeting on 10 and 11
----------------------------
Please post more info if you have.

The call closed at 15:02 UTC

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en
--
PLEASE READ: This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.





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


More information about the Openid-specs-ab mailing list