[Openid-specs-ab] Spec call notes 1-Feb-18

[Mike Jones]

Spec call notes 1-Feb-18

George Fletcher
Phil Hunt
Mike Jones
Brian Campbell
Rich Levinson
Roland Hedberg
Bjorn Hjelm
Ravi Kumar Kanukollu (CA)
Nat Sakimura

Agenda:
              Federation Draft
              Open Issues
              OAuth AS Metadata Draft
              Roland's new Python library and interop issues encountered

Federation Draft
              There weren't many changes
              A few metadata field names were changed
              Roland: There is experience from large-scale academic federations in also having communities
                           There are also "communities" as well as full-scale federations
                           A companion document was written by a Spanish person about this
                           https://github.com/OpenIDC/fedoidc/blob/master/doc/howto/multifederation.md
                           We need to sort out what the relationship is to the main federation draft
                           Communities typically don't impose many policies
                           But there will be a federation key
              People are doing pilots of the federation draft

Open Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              No new open issues
              Issue #984: Create a document explaining "single logout" semantics
                           Mike submitted a position paper to the upcoming OAuth security workshop requesting that we discuss this

OAuth AS Metadata Draft
              There was an IESG DISCUSS on appending .well-known to an issuer with a path
                           See the OAuth mailing list for details
              This violates BCP 190, so we're not going to get this published as-is
              Adam Roach's suggestion was to put the path before the .well-known URI, rather than after it
                           This is the same when there's no path in the issuer but different if there is
              Practically, this means that some software implementing both Connect Discovery and this draft will end up doing both
                           This is unfortunate, but hundreds of implementations already implement Connect Discovery and the IESG won't budge
              The Connect Discovery errata will register metadata values in the registry created

Roland's new Python library and interop issues encountered
              Roland has built a new RP library
              He tried testing against Google, Facebook, LinkedIn, Salesforce, Amazon, GitHub, and Okta so far
              Most large OPs aren't fully following the Connect specifications
                           Some implement OAuth with extensions but not really connect
                           What is returned from the Token Endpoint varies
                           Some have gotten rid of client authentication, for instance
              George Fletcher has seen numerous differences as well
                           For instance, not ignoring not-understood parameters
                           We can add negative tests about these things in the certification test suite
                           He's seen problems when a scope value is sent to the token endpoint when the grant type is authorization code
                           Brian cautions that scope is a known parameter - not an unknown parameter
                           Mike made the point that RPs can shield themselves from this by not venturing beyond the specs
                                         Sending a scope parameter to the token endpoint in this case is going beyond the specs
              Roland would like people to send him a note when incompatibilities are found
                           George suggests that we could have a community-visible place to put this info
                           We should have conversations about "dead places"/gaps in the spec when they are found
              Nat thinks that we should have a publicly accessible issue tracker for compiling interop issues
                           Mike says that if we do this, we should first talk about it the upcoming board meeting
                                         We haven't typically been shaming people who haven't finished their implementations
                           George thought that maybe we should not identify where the failures occurred
                                         Mike doesn't think it's realistic to not identify where failures occurred
                                         Roland would want specifics so that he can reproduce the problems
              Nat provided a less controversial example
                           One of the implementations broke when it received an Accept: header with charset = utf8 designation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180202/4350167c/attachment.html>