OAuth AS and RS are intended to be loosely coupled. A AS may not have any way to know if data for any or all of an API is populated.
At the API layer the client needs to be able to deal with the API appropriately including empty responses if that is possible. Not returning a access token my be taken by the client that it is not the resource owner or that they resource owner did not not approve the grant. I can see it being tempting to not send back a token if it is a single use token and there is no data, but I don't think the optimization is worth it. Deal with missing data at the API layer, and Authorization at the OAuth layer. John B. On Feb 10, 2014, at 8:39 AM, Paul Madsen <[email protected]> wrote: > Hi Don, the way I see it, whether or not there is data available at the RS is > mostly orthogonal to any authorizations the client is issued for that data > > But a caveat is the risk of Client's asking for 'omnibus scopes', ie any and > everything on the possibility that the authorizations become relevant in the > future. For instance, Google API clients shouldnt start asking for Nest data > in anticipation of future availability. > > paul > > On 2/10/14, 2:31 AM, Donald Coffin wrote: >> Hi Torsten, >> >> I apologize if this is a duplicate response, but I just realized I responded >> to my greenbutton-dev email address in my initial response and wanted to be >> sure you got my reply. >> >> For the situation under discussion, there is no data at the (2) resource >> server available for the client to access at the time the resource owner >> grants them access. >> >> Best regards, >> Don >> Donald F. Coffin >> Founder/CTO >> >> REMI Networks >> 22751 El Prado Suite 6216 >> Rancho Santa Margarita, CA 92688-3836 >> >> Phone: (949) 636-8571 >> Email: [email protected] >> >> From: Torsten Lodderstedt [mailto:[email protected]] >> Sent: Sunday, February 09, 2014 10:29 PM >> To: Donald Coffin; [email protected] >> Cc: greenbutton-dev >> Subject: AW: [OAUTH-WG] Should data exist for an Oauth access token request >> to be granted? >> >> Hi Donald, >> >> do you mean data regarding the particular user do not exist (1) at the >> authorization server or (2) the resource server? >> >> Regards, >> Torsten. >> >> >> -------- Ursprüngliche Nachricht -------- >> Von: Donald Coffin >> Datum:10.02.2014 03:22 (GMT+01:00) >> An: [email protected] >> Cc: greenbutton-dev >> Betreff: [OAUTH-WG] Should data exist for an Oauth access token request to >> be granted? >> >> We are having a bit of a philosophical discussion regarding the requirement >> for data to exist as a requirement for an OAuth 2.0 access token to be >> granted and I’d like to get the opinions of the IETF Oauth WG. >> >> The two points of view are: >> >> · There are no requirements in “The OAuth 2.0 Framework” [RFC6749] >> specification that requires data to exist prior to an access token being >> granted and therefore the requirement that data exist should NOT be a >> consideration for granting or denying an access token request, as long as >> all of the other requirements for granting of an access token are met. >> >> >> >> · There are many potential applications that are a one-shot access >> request. These would be confused if they receive an access token allowing >> them to access information that does NOT exist. >> >> >> A potential solution that might meet both requirements is to add a SCOPE >> parameter the client MAY provide indicating an access token should only be >> issued if data does exist. The default would be that absent the SCOPE >> parameter the Authorization Server would issue an approved access token >> regardless of the existence or absence of data at the time of the request. >> >> I’d like to hear what the WG feels is a best practice solution to resolve >> our existing implementation conflict. >> >> Best regards, >> Don >> Donald F. Coffin >> Founder/CTO >> >> REMI Networks >> 22751 El Prado Suite 6216 >> Rancho Santa Margarita, CA 92688-3836 >> >> Phone: (949) 636-8571 >> Email: [email protected] >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
