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/>phil.h...@oracle.com
<mailto:phil.h...@oracle.com>
> On Apr 18, 2016, at 4:20 PM, Justin Richer <jric...@mit.edu> wrote:
>
> 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 <bcampb...@pingidentity.com
>> <mailto:bcampb...@pingidentity.com>> 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
>> <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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
>> - 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
>> > <hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>>:
>> >
>> > 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
>> > <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
>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/oauth
>> > <https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://www.ietf.org/mailman/listinfo/oauth>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
