Re: [OAUTH-WG] OAuth 2.0 Discovery Location

It sounds like we want to return a list of available access tokens “aud” values from AS config discovery endpoint (and also via oauth-meta too?), doesn’t it? and RS config discovery endpoint will return acceptable access token “iss” values, a list of every RS endpoints, required scopes per

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I will include the origin in the next rev. For http header v.s JSON, shall I bring the JSON back in? 2016年2月26日(金) 13:05 Manger, James : > You are right, George, that making the AS track /v2/… or /v3/… in RS paths > is likely to be brittle — but tracking RS web

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

You are right, George, that making the AS track /v2/… or /v3/… in RS paths is likely to be brittle — but tracking RS web origins is not too onerous. PoP has some nice security advantages over bearer tokens or passwords. However, it should still be possible to use the latter fairly safely — but

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Authorization server discovery. > On Feb 25, 2016, at 8:10 PM, Mike Jones wrote: > > Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your > suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 > Authorization Server

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery” Best regards, Don Donald F. Coffin Founder/CTO REMI Networks 2335 Dunwoody Xing #E Dunwoody, GA 30338-8221 Phone: (949) 636-8571 Email: donald.cof...@reminetworks.com From:

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

+1 for “OAuth 2.0 Authorization Server Discovery” On 2/25/16 2:10 PM, Mike Jones wrote: Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0 Authorization Server Discovery”. While the abstract already makes it clear that the scope of the document is AS discovery, doing so in the title

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

On Thu, Feb 25, 2016 at 4:25 PM George Fletcher wrote: > Interesting... this is not at all my current experience:) If a RS goes > from v2 of it's API to v3 and that RS uses the current standard of putting > a "v2" or"v3" in it's API path... then a token issued for v2 of the API

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat, The information that will be used to update the NAESB REQ.21 Standard can be found at http://greenbuttondata.org. The document that defines the Authorization requirements is referenced as the “GreenButton Implementation Agreement

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

I made a mistake in my response (good to never rush things :) My +1 was for moving the suggested metadata params from the "Link" header to the JSON object that represents the token response. Because in there we already have the token itself and associated metadata (expiration and scope). I still

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

That said, I'm not against the AS informing the client that the token can be used at the MailResource, ContactResource and MessagingResource to help the client know not to send the token to a BlogResource. However, identifying the actual endpoint seems overly complex when what is really trying

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard of putting a "v2" or"v3" in it's API path... then a token issued for v2 of the API can not be sent to v3 of the API, because v3 wasn't wasn't

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Interesting. Is there a link that I can download your spec etc. ? I have not much preference over the actual endpoint link or the web origin. As long as the semantics is clear, either is fine. I was even considering using URI template. It will be extremely flexible, but I am not sure about the

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

The AS knows the RS's that will consume it's tokens because it knows the scopes that it can allow the user to authorize. I don't think the AS MUST know the endpoints of the RS (which is what the current drafts require). It is not often that the entity/group responsible for the Authorization

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

In fact, this is the method being used by utilities implementing the Green Button Connect My Data interface (North American Energy Standards Boards' (NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider Interface - ESPI). The Green Button Alliance is in the processing of

[OAUTH-WG] (no subject)

-- J Dred from -- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

In OIDC the discovery doc is of great utility to developers and integrators. Developers also tend to find it a more accurate and complete description of how to set up a client for a particular deployment, compared to traditional online docs, which may be not be up to date, or even missing. Very