Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Next Steps for the JSON Web Token Document I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.html from Hannes noting reviews on draft-ietf-oauth-json-web-token and was surprised that mine wasn't included. So I went lookin

Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

Thank you for your review, Brian. Am 01.11.13 20:53, schrieb Brian Campbell: I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.html from Hannes noting reviews on draft-ietf-oauth-json-web-token and was surprised that mine wasn't included. So I went looking for it and apparen

Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.htmlfrom Hannes noting reviews on draft-ietf-oauth-json-web-token and was surprised that mine wasn't included. So I went looking for it and apparently I didn't actually send it to the list. But I did find it and am including wha

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

Thanks for the review and feedback, Torsten, and apologies for the slow reply. Responses to your questions are inline below and in some cases have additional questions for you and/or the WG at large. On Sat, Sep 28, 2013 at 7:36 AM, Torsten Lodderstedt wrote: > Hi all, > > here are my comments:

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

Hi all, here are my comments: --- Assertion Draft --- section 4.1. "Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of client authentication that relies on the parameter is used

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

On 19.09.2013 17:48, Mike Jones wrote: I also think that the text is already there and these specs are ready to progress as-is. If anyone disagrees, please let us know what text needs to be changed or added. I dropped Barry a mail and I will have to carefully re-read the documents myself in p

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, September 10, 2013 11:38 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts Regarding the second item about additional SAML related text - such text already exists in the

Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

No comments - everything is fine "Tschofenig, Hannes (NSN - FI/Espoo)" schrieb: >Hi again, > >I also checked the minutes from IETF#87 regarding the JWT and here are >the action items: > >** I issued a WGLC, as discussed during the meeting: >http://www.ietf.org/mail-archive/web/oauth/current/ms

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

Regarding the second item about additional SAML related text - such text already exists in the document in §5 [quoted and linked below]. It's unclear to me what else is being asked for here? I'd like to request that some specific and concrete text be proposed, if anyone believes the current wordin

[OAUTH-WG] Next steps on the OAuth Assertion Drafts

Hi all, I am trying to wrap up the assertion documents and I took a look at the meeting minutes from the Berlin IETF meeting and the actions are as follows: ** John & Torsten: Please post your document review to the list. ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the addition

[OAUTH-WG] Next Steps for the JSON Web Token Document

Hi again, I also checked the minutes from IETF#87 regarding the JWT and here are the action items: ** I issued a WGLC, as discussed during the meeting: http://www.ietf.org/mail-archive/web/oauth/current/msg11894.html ** We got some reviews from James, and Prateek. Thanks, guys! Here are the

Re: [OAUTH-WG] Next steps (draft timeline)

The chairs sent a longer list of new items to consider. This does not replace that list but only focuses on the immediate next steps. EHL On Sep 30, 2010, at 8:38, "Torsten Lodderstedt" mailto:tors...@lodderstedt.net>> wrote: Bassically, your suggestion sounds reasonable to me. The only thing

Re: [OAUTH-WG] Next steps (draft timeline)

Bassically, your suggestion sounds reasonable to me. The only thing I'm missing is discovery. As you pointed out in http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ this is a major enabler for interoperable APIs and motivates the need for signatures. Shouldn't we

[OAUTH-WG] Next steps (draft timeline)

(This is a draft overview of our next steps. Clearly, this can change based on working group consensus.) Proposal discussion The working group is still discussing the compromise proposal for moving section 5 out of the specification. So far there is general support but some have raised concern

Re: [OAUTH-WG] Next Steps

A single client could generate multiple requests simultaneously, and have them show up out of order. Allen On 3/24/10 10:06 PM, "Brian Eaton" wrote: > On Wed, Mar 24, 2010 at 9:46 PM, Luke Shepard wrote: >> This is probably a stupid question, but why do we need accurate timestamps? >> Why is i

Re: [OAUTH-WG] Next Steps

On Mar 25, 2010, at 9:55 AM, Brian Eaton wrote: > On Thu, Mar 25, 2010 at 6:09 AM, Subbu Allamaraju wrote: >> Just curious - why can't the client check the Date header? > > Yes, that works, but lots of clients don't realize it is possible. In other words, this is part of HTTP, and should not h

Re: [OAUTH-WG] Next Steps

On 2010-03-25, at 9:55 AM, Brian Eaton wrote: > On Thu, Mar 25, 2010 at 6:09 AM, Subbu Allamaraju wrote: >> Just curious - why can't the client check the Date header? > > Yes, that works, but lots of clients don't realize it is possible. Do all clients have access to it? _

Re: [OAUTH-WG] Next Steps

On Thu, Mar 25, 2010 at 6:09 AM, Subbu Allamaraju wrote: > Just curious - why can't the client check the Date header? Yes, that works, but lots of clients don't realize it is possible. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/l

Re: [OAUTH-WG] Next Steps

On Mar 25, 2010, at 9:09 AM, Subbu Allamaraju wrote: > Just curious - why can't the client check the Date header? It can. Once it got a failed response from the first call. Regards, - johnk > > Subbu > > > On Mar 24, 2010, at 6:26 PM, Paul Lindner wrote: > >> Right now if a client with an

Re: [OAUTH-WG] Next Steps

Just curious - why can't the client check the Date header? Subbu On Mar 24, 2010, at 6:26 PM, Paul Lindner wrote: Right now if a client with an inaccurate clock makes an OAuth call they are rejected. OAuth Problem Reporting includes a mechanism to send the server's concept of 'now' to t

Re: [OAUTH-WG] Next Steps

On Wed, Mar 24, 2010 at 9:46 PM, Luke Shepard wrote: > This is probably a stupid question, but why do we need accurate timestamps? > Why is it not sufficient to use a monotonically increasing call_id to > prevent replay attacks? (this is how the Facebook sig algorithm works) Monotonically increas

Re: [OAUTH-WG] Next Steps

This is probably a stupid question, but why do we need accurate timestamps? Why is it not sufficient to use a monotonically increasing call_id to prevent replay attacks? (this is how the Facebook sig algorithm works) On Mar 24, 2010, at 9:28 PM, Raffi Krikorian wrote: but timestamps are still n

Re: [OAUTH-WG] Next Steps

Paul, I really like your problem reporting mechanism. Although diminishing, problems with time synch and general OAuth are still prevalent with our Netflix developers. Hans On Wed, Mar 24, 2010 at 6:26 PM, Paul Lindner wrote: > Right now if a client with an inaccurate clock makes an OAuth cal

Re: [OAUTH-WG] Next Steps

I am also supportive of this approach. On Mar 24, 2010, at 7:13 PM, David Recordon wrote: > I'm certainly supportive of this approach; Eran has shown that he's a > good editor. :) > > On Wed, Mar 24, 2010 at 10:11 AM, Blaine Cook wrote: >> >> >> Hi all, >> >> Hannes and I have discussed the

Re: [OAUTH-WG] Next Steps

In our experience at Yahoo, we¹ve found that many clients don¹t have the right time. You¹d think that NTP would have solved this by now, but it hasn¹t for a surprising number of clients. Are timestamps really necessary in Oauth 2.0? In OAuth 1.0a, timestamps are included in the signature to protec

Re: [OAUTH-WG] Next Steps

I'm certainly supportive of this approach; Eran has shown that he's a good editor. :) On Wed, Mar 24, 2010 at 10:11 AM, Blaine Cook wrote: > > > Hi all, > > Hannes and I have discussed the results of the WG meeting, and while > there was a lot of good discussion that happened, it seems like the

Re: [OAUTH-WG] Next Steps

Right now if a client with an inaccurate clock makes an OAuth call they are rejected. OAuth Problem Reportingincludes a mechanism to send the server's concept of 'now' to the client: The parameter named *oauth_acceptable_timestamps* consists of two numb

Re: [OAUTH-WG] Next Steps

Hey Paul, I was just curious, what do you mean by OAuth Problem Reporting and clock synchronization? I'm not familiar with those. On Mar 24, 2010, at 4:12 PM, Paul Lindner wrote: > > > Here at LinkedIn we've been following the OAuth developments and we're all > happy to see progress being ma

Re: [OAUTH-WG] Next Steps

Here at LinkedIn we've been following the OAuth developments and we're all happy to see progress being made on 2.0. From our side we'd love to see standardization of a number of defacto standards we use in our implementation. Specifically the following: * OAuth Problem Reporting -- If we h

[OAUTH-WG] Next Steps

Hi all, Hannes and I have discussed the results of the WG meeting, and while there was a lot of good discussion that happened, it seems like the next step for the WG is to buckle down and produce a stable draft that incorporates all the various proposals, in particular WRAP and OAuth 1.0a. David