Hey Elliot,
Have some text to propose?
Thanks,
--David
On Tue, Apr 13, 2010 at 11:05 PM, Eliot Lear wrote:
> It would seem to me that the purpose of this specification should be to
> reduce the amount of work implementers have to do, in order to actually have
> functioning interoperable systems
It would seem to me that the purpose of this specification should be
to reduce the amount of work implementers have to do, in order to
actually have functioning interoperable systems. Otherwise, why even
bother with any of this, and why not simply have each server hand out an
SDK? It seems t
That's copied from 2616. And needs work.
EHL
On Apr 14, 2010, at 8:58, "Eliot Lear" mailto:l...@cisco.com>>
wrote:
In terms of looking for ways to reduce the document size ;-)
Section 2.5 is redundant with Section 2.4 and the IETF doesn't talk in terms of
conformance but interoperability.
El
In terms of looking for ways to reduce the document size ;-)
Section 2.5 is redundant with Section 2.4 and the IETF doesn't talk in
terms of conformance but interoperability.
Eliot
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l
In the latest draft of the OAuth 2.0 spec, there are four "User Delegation"
flows:
3.4.1 Web Callback Flow
3.4.2 Native Application Flow
3.4.3 User-Agent Flow
3.4.4 Device Flow
The Native Application and the User-Agent flows should be combined into one
flow. The combined flow works for
As far as I know, JavaScript code can set headers, incl. Authorization
Headers, using the operation setRequestHeaders of the XMLHttpRequest
Object
XMLHttpRequest is limited to the same domain (example.com can make calls to
example.com). When making cross domain requests (example.co
At least with regards to the language preference, how about if we just copy
the openid.ui.lang parameter from the OpenID UI Extension?
http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-u
ser-interface-extension-1_0.html#anchor3
In flows in which the client redirects the u
+1
In Yahoo¹s case, we would also like to use the Client Credentials Flow for
all ³2 legged² APIs.
Allen
On 4/12/10 6:29 PM, "Luke Shepard" wrote:
> In Facebook¹s case, we would like to make our entire API accessible
> exclusively via OAuth including properties, metrics, etc. For our purpos
Awesome, on my calendar. Thanks!
On Tue, Apr 13, 2010 at 9:08 AM, Tschofenig, Hannes (NSN - FI/Espoo)
wrote:
> Hi all,
>
> This is an early warning!
>
> As mentioned at the last IETF meeting we are thinking about organizing a
> face-to-face interim meeting attached to the Internet Identity Works
Hi all,
This is an early warning!
As mentioned at the last IETF meeting we are thinking about organizing a
face-to-face interim meeting attached to the Internet Identity Workshop
(see http://www.internetidentityworkshop.com/) on the 20th of May (in
Mountain View). As a host we have tentatively
Is this really a MUST?
EHL
On 4/13/10 7:23 AM, "jbem...@zonnet.nl" wrote:
All,
I think the draft should explicitly state that the Authorization server
MUST use Cache-Control: no-store on all responses that contain tokens
or other sensitive information, since this is critical to the security
p
Hello..
Despite the fact that it might complicate the spec, I would like to see the
ability to get a token secret without having to make an extra refresh token
request.. if "secret_type" were added to the request parameters in 3.4.1.2
(Client Requests Access Token), the response could contain
All,
I think the draft should explicitly state that the Authorization server
MUST use Cache-Control: no-store on all responses that contain tokens
or other sensitive information, since this is critical to the security
properties of the protocol
Regards,
Jeroen
___
Eran,
> I agree
Thanks.
> , BUT.
> I don’t think it is very practical at this point. Defining new authentication
> schemes (i.e. SAML assertion) means slower deployment due to lack of support
> in existing applications.
There are no existing apps that support the SAML flow as it was only wr
14 matches
Mail list logo
