[OAUTH-WG] Meeting Minutes

[Hannes Tschofenig]

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

[Gil Kirkpatrick]

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:oauth-***@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, April 7, 2016 3:14 AM
To: ***@ietf.org
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

[Brian Campbell]

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 <

Post by Hannes Tschofenig
Leif was so nice to take meeting notes during the OAuth meeting today
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

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

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.
Leif was so nice to take meeting notes during the OAuth meeting today
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth <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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

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.

Post by Hannes Tschofenig
Leif was so nice to take meeting notes during the OAuth meeting today
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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 <

Post by Torsten Lodderstedt
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
- 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 <
Leif was so nice to take meeting notes during the OAuth meeting today
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

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

— Justin

Yeah, as I recall, there was at least some support around the idea of an "enhanced OAuth security" document.
Hi all,
- 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.

Post by Hannes Tschofenig
Leif was so nice to take meeting notes during the OAuth meeting today
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth <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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

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

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

Yeah, as I recall, there was at least some support around the idea of an "enhanced OAuth security" document.
Hi all,
- 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.

Post by Hannes Tschofenig
Leif was so nice to take meeting notes during the OAuth meeting today
https://www.ietf.org/proceedings/95/minutes/minutes-95-oauth <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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Hannes Tschofenig]

Hi Torsten,

Post by Torsten Lodderstedt
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.

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

[t***@lodderstedt.net]

Different people, different perceptions :-)

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

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Meeting Minutes

Post by Hannes Tschofenig
Hi Torsten,

Post by Torsten Lodderstedt
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.

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

[Hannes Tschofenig]

Post by t***@lodderstedt.net
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

[Nat Sakimura]

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:oauth-***@ietf.org] On Behalf Of ***@lodderstedt.net
Sent: Tuesday, April 19, 2016 5:17 PM
To: ***@gmx.net; ***@pingidentity.com
Cc: ***@ietf.org
Subject: Re: [OAUTH-WG] Meeting Minutes



Different people, different perceptions :-)

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



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Meeting Minutes
Von: Hannes Tschofenig <***@gmx.net <mailto:***@gmx.net> >
An: Brian Campbell <***@pingidentity.com <mailto:***@pingidentity.com> >,Torsten Lodderstedt <***@lodderstedt.net <mailto:***@lodderstedt.net> >
Cc: ***@ietf.org <mailto:***@ietf.org>

Hi Torsten,

Post by Torsten Lodderstedt
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.

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