ideas. I still hope to get the discovery spec finished in the same timeframe,
but have no plans to author or edit any other draft.
Just to get this clear. Do you plan to author the discovery spec? And what is
the core spec's timeframe?
I have started to write the discovery spec, but work on the core spec has taken
most of my free time to do this (OAuth is not part of my day job).
The same holds for me :-) Would you mind to share your thoughts
regarding discovery with the group. I especially would like to know,
whether you agree with the requirements I described in "OAuth Discovery
Requirements" and how they can be met.
I have no idea what's the timeframe for the core spec. This groups isn't very
good at providing timely feedback and staying focused.
Good point. What might be the reasons for the missing focus? In my
opinion, there are a couple of.
First of all, what is the "thing" we shall be focusing on? That's not
clear to me (probably also to others). I therefore asked for your plans
to include several aspects in the core spec. Moreover, it's also not
clear to me what complementary specs and sub-sequent versions of the
core spec the WG will produce in the future. As an effect, everyone is
afraid that his/her own ideas are not being considered and focuses on
advocating them. If we find a WG consensus on the core spec or "first
stage" and also the additional WG items, work will probably become more
focused. My impression after attending IETF 78 is, bringing the core
spec through the IETF approval process will be hard enough!
Additionally, I think the WG lacks consensus on what OAuth 2.0 should
be, especially regarding fundamental architectural questions and there
consequences! Just to list a few:
- supported use cases and client types (there is more than web clients :-))
- number of resource servers an authorization can handle (1:1 vs. 1:n)
(resource server specific tokens + resource server addressing)
- supported token types (self-contained vs. artifacts vs. session ids)
- usage of scopes (resources vs. resource server vs. permissions vs.
duration vs. ...)
- role of signatures (none, authentication, prove of posession, message
integrity, ...) + key management approaches
- security level (none, relaxed, state-of-the-art, paranoid), probably
there is a need for different OAuth security profiles
This not only results in a spec difficult to understand for an
"outsider". It also causes endless discussions around those or derived
topics.
So far no one has offered to work on the security consideration section
(Brian's draft is too far from the format I need to incorporate).
I could work on this topic, if Brian does not insist to do so.
@Brian: What do you think?
From my point of view, the security considerations could be worked out
on a per flow/profile base by multiple contributers (anyone
interested?). At least we should agree on a common set of threat agents
and a template.
I am planning the next draft for early September which will include the few
changes raised on the list, but will focus on finding a middle ground between
detailed profiles and a generic architecture (editorial work).
Good luck!
regards,
Torsten.
EHL
What about the following topics?
- security considerations
That's part of core and someone has to write it. I'd like to see someone
take the security section from RFC 5849 and rework it to match 2.0, as well as
add everything that is missing. I will incorporate it and take care of the
editorial work but I am not writing it from scratch.
- token revocation (requested by several attendees during Maastricht
WG meeting)
Someone needs to write a proposal and work to get WG consensus (to the
point where enough people say they like it and no one is objecting). Get it
there, I'll do the rest. Feel free to ask the chairs to help out.
- signatures
I think Nat offered to take a stab at a first draft based on Dirk's work and
the WG discussions. I have offered to help with editorial work if requested.
EHL
regards,
Torsten.
Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav
<[email protected]>:
General discussions on the list and during the interim meeting.
EHL
-----Original Message-----
From: Torsten Lodderstedt [mailto:[email protected]]
Sent: Monday, August 02, 2010 1:20 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] Extensibility: new endpoints
What consensus do you refer to? The WG charter?
regards,
Torsten.
Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav:
No according to WG consensus. We took it all out because too many
people considered it experimental, so while it may be a WG item, it
is not part of the core spes.
EHL
-----Original Message-----
From: Torsten Lodderstedt [mailto:[email protected]]
Sent: Monday, August 02, 2010 1:07 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email protected])
Subject: Re: [OAUTH-WG] Extensibility: new endpoints
and discovery does not belong into the core?
regards,
Torsten.
Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav:
This doesn't belong in core. A registry is used to avoid name
collisions, not
to provide an inventory.
Maybe in discovery.
EHL
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Torsten Lodderstedt
Sent: Monday, August 02, 2010 12:54 PM
To: OAuth WG ([email protected])
Subject: [OAUTH-WG] Extensibility: new endpoints
the existing authorization server endpoints (end-user authorization
and tokens endpoint) have a relatively clearly semantics and scope.
Adding distinct new functions to an authorization server will (in my
opionion) require the definition of new endpoints. For example, I'm
working on an I-D for token revocation. Such a function does not fit
into the tokens endpoint since it has become a "token issuance
endpoint" rather than a general purpose client2server endpoint.
I therefore would propose to include the option to define and
register new endpoints into the Extensibility section of the spec.
This would also facilitate the incorporation of additional endpoints
(with well- defined names) into OAuth discovery.
Any thoughts?
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
