Here are the minutes from the call:
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/minutes/minutes-interim-2013-oauth-2
Here are the uploaded slides:
http://www.ietf.org/proceedings/interim/2013/01/21/oauth/slides/slides-interim-2013-oauth-2-0.ppt
OAuth Conference Call - 21th Jan
On 01/24/2013 12:16 PM, Anthony Nadalin wrote:
Basically the spec has a lot of underspecified behaviors which will
lead to issues, in security and in expectations of the client.
3. no, as I can't do anything with an auth_code except get a access_token
Right. Which is *exactly* how I'm sugge
Basically the spec has a lot of underspecified behaviors which will lead to
issues, in security and in expectations of the client.
3. no, as I can't do anything with an auth_code except get a access_token
5. The client does not know what to throw out as it does not know the server's
policy
7." n
1. We have WebFinger lets use that as we have already been through the
discovery issues, point being there are security issues at stake here w/o
proper knowledge, next thing we know some rouge sever has signed up as a
revocation sever.
Tony, I think you're misunderstanding what I'm saying. I
1. We have WebFinger lets use that as we have already been through the
discovery issues, point being there are security issues at stake here w/o
proper knowledge, next thing we know some rouge sever has signed up as a
revocation sever.
3. you can still have one if you have not used it and want t
On 01/24/2013 10:58 AM, Anthony Nadalin wrote:
1. we keep punting on discovery, this has an impact on security of where I send
my credentials and token, can't see punting yet again here
It doesn't make any sense to solve discovery *just* for revocation,
which you seem to be advocating. Of cour
U uggg
1. we keep punting on discovery, this has an impact on security of where I send
my credentials and token, can't see punting yet again here
2. OK, make this explicit in specification
3. if you have an auth_code you should be able to use it, agree not all will
have it but some will
4. M
On 24/01/13 14:26, Justin Richer wrote:
On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
I like this most, would rename it to say
/oauth/client/registration
or
/oauth/client-registration
etc
and reword the spec such that it will let those who implement do it
with one endpoint or many, whatev
Well, you *can* have it both ways. But to your point Justin - what's the
value in it? Allowing for both adds a bunch of unnecessary complexity while
only adding flexibility for the sake of flexibility with no tangible
benefit.
On Thu, Jan 24, 2013 at 7:26 AM, Justin Richer wrote:
>
> On 01/24/20
On 01/24/2013 05:56 AM, Sergey Beryozkin wrote:
I like this most, would rename it to say
/oauth/client/registration
or
/oauth/client-registration
etc
and reword the spec such that it will let those who implement do it
with one endpoint or many, whatever is preferred
That's the whole poi
Not to jump in and answer for Torsten, but I thought I'd offer at least
my understanding of the document:
On 01/23/2013 06:54 PM, Anthony Nadalin wrote:
1. Since not stated I assume that the Revocation Endpoint can exist on a
different server from the Authorization server (or is it assu
On 23/01/13 20:22, Justin Richer wrote:
While Eve is right in principle, I think it's better for everyone if
things remain consistent across different endpoints where possible. This
is why registration now does form input and json output, for instance.
Still simple, not as RESTy, but ultimately R
On 23/01/13 18:05, Justin Richer wrote:
I am very confused, and I need someone to explain to me what I am
missing. Why won't it work to just pick one? What are people "already
stuck with" that this would affect? It's not like we're trying to unseat
a well-established protocol with a wide installa
13 matches
Mail list logo
