Subject: [OAUTH-WG] Meeting Minutes

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Apr 2016 19:43:59 +0200

Leif was so nice to take meeting notes during the OAuth meeting today
and they have been uploaded to:
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth

Please take a look at them and let me know if they are incorrect or need
to be extended.

Ciao
Hannes

---

From: "Gil Kirkpatrick" <[email-masked]>
Date: Fri, 8 Apr 2016 09:43:58 +1000

>> John Bradley sang a few notes from the Sound of Music to end the meeting.

Were the hills alive? :)

-gil

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 7, 2016 3:14 AM
To: [email-masked]
Subject: [OAUTH-WG] Meeting Minutes

Leif was so nice to take meeting notes during the OAuth meeting today and they have been uploaded to:
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth

Please take a look at them and let me know if they are incorrect or need to be extended.

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 06:21:08 -0600

Under the Token Exchange part it says, "Jim Fenton: we have implmentation
that could be adapted to this." but, as I recall, Jim was not speaking for
himself there but rather on behalf of Justin via the Jabber room.

On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 12 Apr 2016 08:40:49 -0400

That’s correct, we’ve filed an issue in our project to track its eventual implementation:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/1055 <https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/1055>

 — Justin

> On Apr 11, 2016, at 8:21 AM, Brian Campbell <[email-masked]> wrote:
> 
> Under the Token Exchange part it says, "Jim Fenton: we have implmentation that could be adapted to this." but, as I recall, Jim was not speaking for himself there but rather on behalf of Justin via the Jabber room.  
> 
> 
> 
> On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth <https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 17 Apr 2016 10:46:10 +0200

Hi all,

the security discussion started with mix up and cut and paste, but we had a much broader discussion including further issues, such as open redirector. I suggested to merge all threats we are currently discussing into a single document in order to come up with a consolidated view on "enhanced OAuth security". This would at least include:
- mix up
- copy and paste
- changed behavior of browsers regarding URL fragments
- open redirector (AS and client)
- (potentially) XSRF and advice on how to mitigate it using state

I think that would help the working group to get an overview on ALL issues (including e.g. fragments) and _systematically_ improve OAuth. We did the same when we originally published the core spec - and it worked.

I felt some consensous around the topic that in the end, there must be normative chances to the core protocol and the respective security considerations.

Barry gave his advice regarding updates in this context.

best regards,
Torsten.

> Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <[email-masked]>:
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 18 Apr 2016 16:34:41 -0600

Yeah, as I recall, there was at least some support around the idea of an
"enhanced OAuth security" document.

On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi all,
>
> the security discussion started with mix up and cut and paste, but we had
> a much broader discussion including further issues, such as open
> redirector. I suggested to merge all threats we are currently discussing
> into a single document in order to come up with a consolidated view on
> "enhanced OAuth security". This would at least include:
> - mix up
> - copy and paste
> I think that would help the working group to get an overview on ALL issues
> (including e.g. fragments) and _systematically_ improve OAuth. We did the
> same when we originally published the core spec - and it worked.
>
> I felt some consensous around the topic that in the end, there must be
> normative chances to the core protocol and the respective security
> considerations.
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 18 Apr 2016 19:20:56 -0400

I recall +1’ing that idea in the chat. It’s an “updates” to 6819 at least.

 — Justin

> On Apr 18, 2016, at 6:34 PM, Brian Campbell <[email-masked]> wrote:
> 
> Yeah, as I recall, there was at least some support around the idea of an "enhanced OAuth security" document. 
> 
> On Sun, Apr 17, 2016 at 2:46 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> > Am 06.04.2016 um 19:43 schrieb Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>:
> >

---

From: Phil Hunt <[email-masked]>
Date: Mon, 18 Apr 2016 16:34:49 -0700

There were multiple options discussed in the meeting and on the emails.

I noticed there was strong support for consolidation if there is an opportunity to reduce the number of RFCs developers have to pay attention to.  This is where Barry commented that there are differences between a 6749bis, vs an UpdateBy vs. adding more drafts.

I’m not sure what the best RFC approach is, but if I was to re-organize the drafts to make life easy for implementers I would start to break things down into distinct areas where there is minimal overlap (except with core). Maybe something along the lines of...

*  Core — what is the core protocol and the security measures that apply to all implementations
*  Functional Cases
   — Mobile - threats and remediation that apply to mobile applications
   — Browser - threats and remediations that apply to javascript apps
    — Dynamic clients - Formalizing how client applications configure at run time or on the fly and/or talk to more than one service provider or oauth service. This can also include dynamic registration.
   — Dynamic Resources - Resource services that are deployed against multiple different OAuth infrastructure providers (e.g. hosted in multi-clouds), or accept authorization/tokens from more than one authorization service. This may include formalization of how resource express or register scopes with ASes and how they register to be served.

Regarding Dynamic Resources, we haven’t really discussed this. But it seems like many AS’s are now issuing generic tokens in enterprise scenarios because they actually know nothing about the resources they are controlling access to. Potentially this is because resources are spun up and taken down independently.  This seems to be its own set of problems and risks that would be worth discussing in its own document. Some of this has been discussed in the UMA cases, but I’m not sure the UMA proposals work in the broader application space.  Certainly we can be informed by the UMA work here.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Apr 18, 2016, at 4:20 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Apr 18, 2016, at 6:34 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Apr 2016 09:51:31 +0200

Hi Torsten,

> Barry gave his advice regarding updates in this context.

There was no consensus on this topic during the meeting and, in
addition, we have to consult those on the mailing list as well.

Barry, in my understanding, outlined the different options we have at
the meeting.

Ciao
Hannes

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 19 Apr 2016 10:17:04 +0200

Different people, different perceptions :-)

But anyway, the discussion on the list has already started, right?

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Apr 2016 10:21:12 +0200

> But anyway, the discussion on the list has already started, right?

I triggered the discussion since I believe it is a worthwhile topic to
think about and, given that it is a bigger decision, we should be
mindful about the direction we take

Ciao
Hannes

---

From: "Nat Sakimura" <[email-masked]>
Date: Wed, 20 Apr 2016 14:49:58 +0900

I recall the same with Torsten and Brian. 

At least, there was a sentiment in the room that we have to come up with a comprehensive analysis of the security model and threat to come up with a proper solution. 

Trying to keep patching the protocol because you can would not be helpful. 

Nat

--

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.

From: OAuth [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 19, 2016 5:17 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Meeting Minutes

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Meeting Minutes
Von: Hannes Tschofenig <[email-masked] <mailto:[email-masked]> >
An: Brian Campbell <[email-masked] <mailto:[email-masked]> >,Torsten Lodderstedt <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 

Hi Torsten,

Ciao
Hannes