Wiki

Clone wiki

connect / Connect_Meeting_Notes_2019-01-21_Pacific

OpenID AB/Connect Call Note (2019-01-21)

Date: 2019-01-21 23:00 UTC

Location: GoToMeeting https://www3.gotomeeting.com/join/695548174

The meeting was called to order at 23:08 UTC.

1.   Roll Call

  • Present: Nat, John, Edmund
  • Regret:

2.   Adoption of the agenda

  • Since draft agenda was not sent out, the following topics were dealt with.

3.   Self-issued OP (Nat/John)

Nat asked John about the outcome of the W3C meeting in December and John reported that while there seems to be a concensus in creating a DID WG, the scope still is not clear.

Nat suggested that "tightening-up" of the Self-issued OP (SIOP), such as the protocol between the SIOP and the claims provider to fetch the claims and construct an "aggregated claims" response, should go ahead without respect to it. Everyone in the call agreed on it.

Edmund reported that the key export functionality of his implementation is almost done.

4.   Status of OAuth JAR (Nat/John)

OAuth JAR spec is still stuck in the queue. There is one change required:

  • aud restriction of the token.

Also, there is a few nits:

  • Downref: Normative reference to an Informational RFC: RFC 6819
  • Downref: Normative reference to an Informational RFC: RFC 6973
  • Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)

John expects it to be finished by the end of next week.

5.   Issues from the tracker

5.1.   Issue #1063: Guidance around algorithm migration (Nat)

Callers discussed the issue and through checking the relevant specifications came to the folloowing observations.

  • OpenID Connect Core puts no restriction on just using the parameter specified by the OpenID Connect Dynamic client registration;
  • JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523] does not put any restriction either;
  • OAuth DynReg [RFC7591] says nothing on the algorithms;
  • OpenID Connect Dynamic registration (OCDR) puts the following restriction in the definition of request_object_signing_alg * This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter).
  • There is nothing that requires the client to use OCDR.
  • Even if OCDR was used, the parameter is optional. So, if the client and server want algorithm agility, which they should, SHOULD NOT use this parameter. Perhaps we can add this "NOTE" in the errata.

As a side topic, the callers agreed that perhaps we should do a limited revision of the specs as we approach the 5 year anniversary of the specs, such as:

  • fix this problem with the OCDR;
  • fix the duplicated authorization request parameters after OAuth JAR is done. Note that this one will be a normative change and cannot be done by an errata.

6.   AOB

As the time has run out, we could not get to any other issues such as:

6.1.   Topics for the next call:

  • Status of errata
  • #1055: Limits on overall url length (Joseph)
  • #1054: Do a survey on the revision of the OIDC (Nat)
  • #1053: Impact of ITP2 on implicit flows (George)
  • #1052: make clear that nonce is always required for Hybrid flows (Hans/Brian)

The call closed at 00:09 UTC

Updated