1. Why are you here? What are you trying to solve that is not
already addressed by existing specifications (OAuth 1.0a, WRAP, etc)?
I am working on the security aspects of identity management, and I find
that OAuth is trying to solve an essential piece of the puzzle there as
far as delegation is concerned. I also observe that telecom
providers--my customers--are interested in OAuth (and may be seeing
there what I don't yet see). This is another motivation for me--I am
very interested in integrating telecom and Web 2.0. (In fact, I started
in the IETF 14 years ago by bringing that proposal...)
2. Should the WG start by taking WRAP or OAuth 1.0a as its
starting point? Something else?
Something else: Use cases and the requirements. The WG must produce the
requirements based on agreed use cases. Now, it is absolutely clear that
both the WRAP and 1.0 people will ensure that their interests and
agendas are reflected in the requirements, and this is fine, this is how
we will ensure that OAuth WG synthesize both. Personally, I think that
WRAP is much cleaner than OAuth 1.0, and I like clean things. But I also
see some cases where WRAP would not be applicable.
To this end, use cases is the best mechanism to express the vision of
the WG. I would start with them first (in the informational RFC),
meaning that the can be developed in parallel with the requirements.
I don't think Hannes said that in exactly same words, but I suspect that
he and I have the same idea here.
3. If we start from draft-hammer-oauth, what needs to change
to turn it into OAuth 2.0?
4. If we start from draft-hardt-oauth, what needs to change to
turn it into OAuth 2.0?
(Since I chose the "something else" option in item 2, questions 3 and 4
are not applicable.)
5. Do you think the approach of working first on 'how to use a
token' and then on 'how to get a token' is right?
Maybe. But even then, once it is clear' how to use a token', when
working on 'how to get a token' this clarity will be less apparent, so
this subject would need to be revisited.. When you do things like that,
there is always a recursion (and it is not bad).
To make things more effective, I strongly agree with Hannes that the
objectives (in terms of use cases and requirements) must come first.
6. Should we go back to working on a single specification?
I am not sure that this should be an objective. Of course, if everything
is simple, and there is a consensus, this is the best way. But it does
not appear to me that there is a consensus, and if this is the case, it
will be impossible to force one specification. In fact, there has been
a precedent in the IETF where more than one solution was developed and
it was left to the market to choose one.
7. Do you think the protocol should include a signature-based
authentication scheme?
ABSOLUTELY. I thought there has been a good discussion on that, and all
the arguments are on the table.
Respectfully submitted by
Igor Faynberg
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
