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

[Jaromir Talir]

Hi,

as a side note to encountered interop issues, we have a similar problem
 in DNS world and it ended up in creation of DNS violation project
where protocol violations are publicly listed.
https://github.com/dns-violations

I understand, of course, that it is sensitive (political) decision when
members may be included.

Regards,
Jaromir

On Fri, 2018-02-02 at 02:06 +0000, Mike Jones via Openid-specs-ab
wrote:
> 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/ma
> ster/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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-- 
Jaromir Talir
Technicky partner / Technical Fellow
-------------------------------------------
CZ.NIC, z.s.p.o.  --    .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:jaromir.talir at nic.cz  http://nic.cz/
sip:jaromir.talir at nic.cz tel:+420.222745107
mob:+420.739632712       fax:+420.222745112
-------------------------------------------