Please allow me to step-back and present the issue again in a different way:
I think of Section 4.1.1 as an API specification. In my entire career as a
programmer I have never encountered an API specification that said that
some parameters were optional yet callers were required to specify them b
I am just not yet convinced that it should be REQUIRED. I think the fact that
we have default language for servers to insert a NULL value for omitted params
is sufficient. Do we need that here too? Would that make it clearer?
From: agks mehx
To: William Mi
That's fine and still consistent with the essence of (a), which is to
require implementations to accept requests without a scope parameter. If
an implementation chooses to issue scoped credentials, that's perfectly
fine.
My focus is solely on whether the scope parameter should be termed as
OPTION
Re your "a" below: No, implementations may issue scoped credentials if they
have a default scope. It says elsewhere in the spec that the scope issued by
the server may not match the requested scope, which is why the server returns a
scope value. This is for informational purposes only for the
scope parameter in the HTTP requests.
Two choices stand out to me: (a) keep the scope parameter truly optional
which implies requiring all implementations to implement un-scoped
credentials; (b) make the scope parameter REQUIRED thus removing the
confusion and letting implementations choose whet
There are definitely use cases for un-scoped credentials, which the
implementations I have seen implement as an empty scope. Are you worried
specifically about the scope parameter in the HTTP requests, or as represented
in the credential used to access the PR?
___
Hi SM and Eran,
I am confused again, after re-reading Eran's response, whether or not an
implementation that rejects *missing* (as opposed to empty) scope is
conformant or not. (Eran, your response was a bit ambiguous on whether an
implementation is free to error out on an missing scope parameter
Thanks Eran and others for their responses
FWIW & FYI, OMAP decided to phrase requirements more directly in terms
of authentication to the AS (MUST for web app clients & SHOULD for
native clients) rather than use the confidential/public distinction.
Thanks again for your input
Paul
On 1/9/1
Den 9. jan.2012 kl. 17:35 skrev Torsten Lodderstedt:
> Hi,
>
> an invalid token should cause the server to reply with status code 401.
Thanks for the tip, both of you.
Andreas___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf
Hi,
an invalid token should cause the server to reply with status code 401.
regards,
Torsten.
Bart Wiegmans schrieb:
Hi,
As far as I know, the implementation of API endpoints is outside of the
specification of OAuth.
But the specification of Bearer Tokens state that the endpoint must retu
The text is pretty straight forward in its intentions. A confidential client
must had a secret - what's open is how well the secret needs to be protected
(e.g. hard to extract) to qualify as 'capable of keeping' secrets. You can
require all clients to be confidential, but without specifying what
Just return HTTP 5xx. We needed the special error code because of the
redirection flow.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Antonio Sanso
Sent: Friday, December 30, 2011 10:22 AM
To: OAuth WG
Subject: [OAUTH-WG] Error code for access token request
Hi *
In general, you are correct. However in this case, since OAuth 2.0 does not
attempt to guarantee interop between a generic client and any vendor, the
vendor has the right to define its own requirements as long as they are within
the spec boundaries.
For example, a vendor can define a missing or
At 14:12 08-01-2012, agks mehx wrote:
I reported this to the vendor and the vendor claims that the IETF
draft specification says scope is OPTIONAL and that means the vendor
is free to make it required in a conforming implementation.
If a bit is said to be optional, it means that it will not ca
Hi,
As far as I know, the implementation of API endpoints is outside of the
specification of OAuth.
But the specification of Bearer Tokens state that the endpoint must return the
HTTP 403 (Access Denied) status code, along with a WWW-Authenticate: Bearer
response header. That should be enough
Hi,
I'm trying to do an OAuth 2.0 library, and got a question:
I cannot find a standardized way for an OAuth protected endpoint to report to
the client that the Token is not valid (expired or revoked). As a library
developer, I'd like to take away as much of possible of the OAuth logic from
th
16 matches
Mail list logo
