Additionally, I would propose to indicate the scope associated with a
token to the client using a scope response parameter. This is
especially useful (1) if the client did not pass a scope parameter but
the server decided to associate a scope based on its policy or (2) if
the user decided to authorize a subset of the requested scope only.
Regards,
Torsten.
Am 07.05.2010 um 07:32 schrieb Torsten Lodderstedt <tors...@lodderstedt.net
>:
what about an additional realm response value?
If there is a binding between realm and token, the client can decide
based on the realm attribute discovered using a WWW-Authenticate
response which token to use.
regards,
Torsten.
Am 07.05.2010 07:06, schrieb Manger, James H:
Every existing use of Cookies, HTTP Basic, and HTTP Digest relies
on clients being told by the server about the sites at which the
secret (cookie/password/token) can be used (and, more importantly,
where is must not be used). This occurs without requiring service-
specific knowledge in the client app. OAuth aims to replace some of
these uses.
HTTP Basic authentication works safely from clients with no service-
specific knowledge because the client knows not to send the
password it gets from the user to other sites.
HTTP Digest authentication allows a password to used to across a
set of domains specified in a WWW-Authenticate response header, but
the password will not be used at arbitrary other sites.
Cookies are sent in requests to the same site, sites with the same
parent, or only https sites, depending on details from the service
when setting the cookie.
To date, OAuth has assumed every client app has lots of service-
specific knowledge to make these choices. OAuth needs to remove the
need for so much service-specific knowledge to be as interoperable
as other standard auth mechanism, otherwise it is a poor replacement.
--
James Manger
From: David Recordon [mailto:record...@gmail.com]
Sent: Friday, 7 May 2010 2:05 PM
To: Manger, James H
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Indicating sites where a token is valid
Hey James,
Do you have a specific example in mind where this either has been
an issue or will be an issue? Most client implementations I've seen
of OAuth (and technologies like OAuth) have a strong binding
between the access token(s), site they were issued by, and user
they belong to. So I haven't heard of this being a problem in the
wild...
--David
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
