[Openid-specs-ab] Spec call notes 20-Mar-17

[Mike Jones]

Spec call notes 20-Mar-17

John Bradley
Phil Hunt
Mike Jones
Edmund Jay

Nat Sakimura and Brian Campbell sent their regrets

The call had been deleted from the calendar again, which may have resulted in the low attendance
                Nat restored it to the shared OpenID calendar right before the call

Agenda
                Open Issues
                Potential confusion between ID Tokens and other JWTs
                Next Call

Open Issues
                Issue #1010: Create a Threat Document about the Misuse of OAuth
                                Nat created a tracking issue to remind us to create this threat document
                                Phil talked about the need for dual audiences in some native app scenarios
                                In some terrible examples, apps were just passing an e-mail address to a server, which performed no validation
                                Mike suggested that we have an ad-hoc discussion about this next week in Chicago
                                We could try to bang out bullet points for a blog post on this topic
                                John said that a symptom of the problem is some developers don't want to have an OAuth AS for their back-end
                                John called the problem "Fake Federation"

Potential confusion between ID Tokens and other JWTs
                Phil wanted to raise this issue with the Connect working group
                John said that for any generic token format, you'll have to decide how to tell one thing from another
                Phil said that there is no type
                Phil said that a SET is distinguished by having an "events" claim
                                But this can be ignored
                There are things that can be done using the audience
                Phil asked what it means for an event to be expired
                                Phil said that historical statements don't actually expire
                                John said that you want the JWT to expire so you don't have to have an infinite cache
                Phil said that "exp" is to be avoided in SETs to avoid confusion between SETs and access tokens
                                John said that this is problematic because then you don't know when you can evict the JWT from a cache
                                John said that if you remove token lifetime, you will eventually regret it
                                It's really about cache control - how long you look for duplicate "jti" values
                Mike pointed out that, as was said on the just-finished RISC call, SET design should primarily happen in the IETF SecEvent WG
                                That way, all the SecEvent WG members can participate in the discussions
                Mike said that confusion between ID Tokens and SETs isn't possible in practice
                                A SET doesn't have a nonce, which ID Tokens for all but response_type=code must
                                For response_type=code, a SET wouldn't be returned as an id_token value by the Token Endpoint
                Mike said that distinguishing between SETs and access tokens should be discussed at IETF
                                A problem is that OAuth says nothing about access token contents
                                Therefore, to even have that discussion, we'd have to start making assumptions about the contents of JWT access tokens
                John said that using different audiences for different protocols is a security best practice that probably applies here
                John said that clients don't currently publish identifiers for themselves, other than the client ID
                                He said that that's probably a mistake
                                Some use cases want an identifier that's dereferenceable
                                John then realized that the sector identifier URI is actually such as thing
                Mike asked whether Roland's federation spec has a dereferenceable client identifier
                                John thinks that it may have dereferenceable client URLs
                John said that having an identifier that's verifiable and not just self-asserted has proven valuable for the Connect issuer
                                We may want to do that for other participants
                                We can talk about this (and many other things!) in Chicago next week

Next Call
                The next call was scheduled for Thursday, March 30th at 7am Pacific Time
                                We decided to cancel that one because of IETF meeting
                The next call will be in two weeks at 4pm Pacific Time on Monday, April 3rd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170321/8534c4f4/attachment.html>