I messed up the conference bridge time; here is the corrected version but the
details are actually the same.
Meeting Number: 702 442 101
Meeting Password: oauth
---
To join the online meeting
---
I so believe that was the intent and what it probably should have said. So
maybe errata makes sense?
On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt"
wrote:
> Hi all,
>
> would it make sense to issue an errata and add a "public" to the sentence
> as follows?
>
> "A _public_ client MAY use the "cl
+1, I believe that was the intent of the edit.
-- Justin
On 08/22/2013 01:33 PM, Brian Campbell wrote:
I so believe that was the intent and what it probably should have
said. So maybe errata makes sense?
On Aug 17, 2013 12:15 PM, "Torsten Lodderstedt"
mailto:tors...@lodderstedt.net>> wrot
A additional life cycle showing how the server can avoid storing state for the client in the current spec.
new use case jwt.xml
Description: XML document
B.2. Stateless Open Registration using JWTOpen registration, with no authorization required on the client registration endpoint. The registratio
Phil, this just brings me back to the question, "why are we doing this in
OAuth" ? Configuration endpoint (nothing to do with OAuth), Registration
Endpoint (too complicated, goes beyond the bounds of OAuth), why not just a
stateless and state full registration message and that's it?
-Origin
Tony, I look forward to seeing the concrete specification and
implementation of your idea.
-- Justin
On 08/22/2013 03:39 PM, Anthony Nadalin wrote:
Phil, this just brings me back to the question, "why are we doing this in
OAuth" ? Configuration endpoint (nothing to do with OAuth), Registrati
Phil, thanks for writing this down. I think that part of the confusion
in this conversation may come from the nature of items such as the
client id, client secret, and even the registration access token. In
many instances, these are simply random values that the server generates
and stores for
I don't think open vs close has a big impact on design. The issue of state full
vs stateless are foundational.
So we need to talk about when and why state full registration is needed.
Phil
On 2013-08-22, at 12:39, Anthony Nadalin wrote:
> Phil, this just brings me back to the question, "why
Agreed.
The problem for dyn reg is most params are optional and passed at reg time. I
think this also represents huge complexity to client app developers since each
sp may be different. Move bulk of info to statement simplifies the registration
and encourages uniformity.
Phil
On 2013-08-22,
But it also assumes, in many cases, a pre-registration step. I think you
might be simplifying for the case of one piece of software with the same
parameters talking to the same server many times. In some sense, it
doesn't matter to a client developer whether they have to send their
display name
TLS doesn't define how servers obtain certificates. It just assumes they are
installed. The same thing is happening here.
I'm not sure why this is objectionable. It is simply a broader model of your
proprietary (meaning specific) solution for BB+.
Phil
@independentid
www.independentid.com
phi
Yes the was the intent.
On 2013-08-22, at 1:38 PM, Justin Richer wrote:
> +1, I believe that was the intent of the edit.
>
> -- Justin
>
> On 08/22/2013 01:33 PM, Brian Campbell wrote:
>> I so believe that was the intent and what it probably should have said. So
>> maybe errata makes sense?
Phil, I'm not objecting to it! I never have been! I've been saying all along
it's a proper extension to the base dynamic registration spec because it
defines optional functionality in addition to said base spec. Why do you object
to it being an extension?
-- Justin
On Aug 22, 2013, at 4:43 PM
True however this is more like a client cert and that didn't take off because
of distribution and maintenance issues.
On 2013-08-22, at 4:43 PM, Phil Hunt wrote:
> TLS doesn't define how servers obtain certificates. It just assumes they are
> installed. The same thing is happening here.
>
>
Specifics?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-08-22, at 1:52 PM, John Bradley wrote:
> True however this is more like a client cert and that didn't take off because
> of distribution and maintenance issues.
>
> On 2013-08-22, at 4:43 PM, Phil Hunt
A new Request for Comments is now available in online RFC libraries.
RFC 7009
Title: OAuth 2.0 Token Revocation
Author: T. Lodderstedt, Ed.,
S. Dronia, M. Scurtescu
Status: Standards Track
Stream: IETF
... Which was just published as RFC 7009. Great work, everyone!
-derek
Hannes Tschofenig writes:
> A big "Thank you" goes to Torsten for working hard to get the document
> through the IETF process.
>
> On Jul 20, 2013, at 4:43 AM, The IESG wrote:
>
>> The IESG has approved the following docum
Sorry, I meant to ping about this document but I've been inundated with
"Real Work(TM)" since Berlin.
Alas, the document expired, which means we need a new version submitted
before we can send it through the process.
Can one get submitted, please?
Thanks,
-derek
Igor Faynberg writes:
> Zhou,
18 matches
Mail list logo
