Hello,
I have a question.
If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for
Good to see you are following along with what's happened.
On Fri, Mar 11, 2016 at 5:00 PM, Anthony Nadalin
wrote:
> Sorry but not true, this started out as “discovery” and now it’s not
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Friday, March 11, 2016 3:59 PM
> *
Sorry but not true, this started out as “discovery” and now it’s not
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 11, 2016 3:59 PM
To: Anthony Nadalin
Cc: John Bradley ; oauth
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
That *is* the sc
That *is* the scope of the current document, which a majority of folks have
agreed with. I was reiterating that the name of the document should reflect
its content, something else that has been widely agreed with.
On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin
wrote:
> Disagree, what purpose i
Disagree, what purpose is this activity solving then, it was being pushed as
what was need to solve the Mix-up, but that is not true. So now you are
suggesting a change in scope and not dealing with discovery.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday,
I tend to agree with John that addressing the concerns Phil raises should
be part of (extension to) the core protocol. And that those kinds of
concerns don't manifest in the way OAuth is typically deployed now.
The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
should keep i
Hi all,
on February 19 I posted a note to the list asking the group to consider
a call for adoption of either
or , see
https://www.ietf.org/mail-archive/web/oauth/current/msg15829.html
I gave time till early March to think about this topic and there was a
lot of feedback on the mailing list.
He
Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) wrote:
>
> John
>
> In many case all the AS has to check is the domain name component to check
> for mitm.
>
> POP and the other solns are dramatically more complex than a simple check.
I was proposing ding that check at the authorizati
There have been way too many issues, confused conversations and discussions on
and off list to have this document move forward, suggest that this be one of
the main items on the agenda for when we meet.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
Sent: Thursday, Marc
John
In many case all the AS has to check is the domain name component to check for
mitm.
POP and the other solns are dramatically more complex than a simple check.
I see it as part of the discovery(bad name aside) problem because we discussed
that if a client finds app.example.com how do we
I think Phil is proposing something different. Should the client send a token
from this AS to that RS.
His goal is to prevent man in the middle attacks where a bad RS gets a AT that
is audianced to/accepted by another RS.
That is separate from the question of if a RS accepts tokens from a g
I am strongly against requiring the AS to know about RS URIs and
managing that based on a client request for a token. I've stated my
reasons previously.
Happy to agree to disagree:)
Thanks,
George
On 3/10/16 10:17 PM, Phil Hunt (IDM) wrote:
Nat,
Agree with your points.
Regarding the last,
+1 for these changes and finishing the doc
On 3/10/16 10:45 AM, Nat Sakimura wrote:
+1 in proceeding with the following changes:
1. Change name to "*OAuth 2.0 Authorization Server Metadata*",
aligning with section 2.
2. Have the AS dictate the URI path suffix through link header in the
On 18 February 2016 at 14:40, Hannes Tschofenig
wrote:
> Hi all,
>
> This is a Last Call for comments on the OAuth 2.0 Discovery specification:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> Since this document was only adopted recently we are running this last
> call for **3 we
Hi William,
sorry for the late response but I just wanted to note that I really
appreciate your efforts around making code available for specifications
we are developing. The implementation efforts that take place currently
with specification writing have always provided a lot of valuable feedback
Hi Michael,
thanks for dropping us a note since I was not aware of the EBU work.
It is always intesting to hear from other communities who have been able
to make use of OAuth for their use cases.
I will take a look at your specification to better understand what you
have been doing in your workin
16 matches
Mail list logo
