What about browsing history? I've just run the JSP below in Tomcat and found
out that Firefox remembers the redirect in the browsing history. It'll be a
problem in a shared desktop or Internet kiosk environment.
JSP:
% String url = http://localhost:8080#access_token=123;;
the existing authorization server endpoints (end-user authorization and
tokens endpoint) have a relatively clearly semantics and scope. Adding
distinct new functions to an authorization server will (in my opionion)
require the definition of new endpoints. For example, I'm working on an
I-D for
This doesn't belong in core. A registry is used to avoid name collisions, not
to provide an inventory.
Maybe in discovery.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Monday, August 02, 2010 12:54 PM
and discovery does not belong into the core?
regards,
Torsten.
Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav:
This doesn't belong in core. A registry is used to avoid name collisions, not
to provide an inventory.
Maybe in discovery.
EHL
-Original Message-
From:
In the WG meeting at Maastricht, I have been asked to write down my
requirements regarding Discovery. And here they are:
Assumptions: Discovery allows a compliant client to automatically obtain
all deployment specific data required to securely access a particular
resource servers as well as
Does anyone see value in client discovery?
A client starts a transaction with an authz server without doing any
registration beforehand. Based on the client id (which can be a URL or
a domain name) the authz server can discover information about the
client, information that normally is provided
Yes, all of these all seem like the right set of use cases. I'm not sure if
I'll have much time to devote to them over the next few months though.
--David
On Mon, Aug 2, 2010 at 2:14 PM, William Mills wmi...@yahoo-inc.com wrote:
Client discovery can be useful for presenting a nicer user
A richer history API is also coming as a part of HTML5.
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html
On Mon, Aug 2, 2010 at 12:47 PM, Brian Eaton bea...@google.com wrote:
On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb oleg_g...@yahoo.com wrote:
What about browsing
I guess I'd need to understand the scenario better before I'd have an
opinion one way or the other. However, I will say that In this
profile I was specifically looking to avoid the complexity that exists
in SAML Web SSO by allowing for multiple assertions and multiple
subject confirmations.
On
So the scenario we have is where there are multiple tokens from attribute and
identity providers need to be delivered to an OAuth authorization server to
satisfy the resource owner's policy of required claims. So this is a case where
a single SAML token/assertion is not enough to satisfy the
On Mon, Aug 2, 2010 at 6:15 PM, David Stanek dsta...@dstanek.com wrote:
I just verified that the Python urllib client does send the fragment to the
server. I've created a patch and will be created a bug on the Python
tracker.
Cool, but this doesn't seem relevant to the user-agent profile.
RFC 2616 (5.1.2) defines the request URI as:
Request-URI= * | absoluteURI | abs_path | authority
And imports 'absoluteURI' from RFC 2396 (3):
absoluteURI = scheme : ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ ? query ]
opaque_part = uric_no_slash *uric
12 matches
Mail list logo
