Hi Tony,
Could you expand a little bit on those issues:
> 4. Multi-tenant support (single endpoint, multiple services)
What does multiple services mean here in the context of dynamic client
registration?
> 5. Internationalization
Where do you see internationalization play a role here?
>
Hi Sergey,
The idea of the audience was to provide a way for the client to indicate the
resource server it wants to talk to explicitly rather than overloading the
scope field. We certainly need that capability for the MAC token work.
The audience information is provided when the client intera
This could be bound up in the client registration process since oauth clients
don't authorize for random "targets".
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)"
wrote:
> Hi Sergey,
>
> The idea of the
Here is the conference bridge and Webex information.
>From an agenda point of view I guess we should start at a basic level, namely
>with what we have already in the dynamic client registration document (and
>folks may have actually missed it). There are two use cases described in the
>WG docu
That's certainly true although the referenced document did not talk
about the registration phase but rather about the time when the client
talks to the authorization server to obtain an access token.
Maybe UMA has provided a story for this already...
On 08/21/2013 06:35 PM, Phil Hunt wrote:
T
I think binding audience at registration time is to limiting as we see audience
being on a per token request level and also see the audience being part of the
restrictions for "act as" or "on behalf of" support
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.o
Yes. The trade off is that each client_id becomes associated with a target.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-08-21, at 9:45 AM, Anthony Nadalin wrote:
> I think binding audience at registration time is to limiting as we see
> audience being on a pe
I think it makes sense to have both, and this would parallel what we've
got with the "scope" parameter today. At registration, the client is
saying "this is what I want to be able to use" and the server is saying
"this is what you're allowed to use". At auth time, the client is saying
"this is
4. So when registration takes place it may be at a single endpoint, but that
endpoint has to have enough info to figure out which virtual registration point
it need to deal with, much like what we had to do in SCIM to support
multi-tenants
5. any info sent to the registration endpoint need a way
Looking at the spec, the problem is you can still only authorize one api at a
time. You couldn't specify multiple audience apis and match them up with
scopes.
A while ago I did start to write some stuff up about a structured scope
specification where scope becomes a JSON multi-value structure
amirabdul...@hotmail.com@nokia.com@ovi.com@yahoomail.com@gmail.com
Sentall outlook from hotmail ovi my Nokia yahoo gmail facebook aol live msn
other e-mail PhoneSoftwarOpera in likes CCLmailGoogle yahoomail
-Original Message-
From: oauth-requ...@ietf.org
Sent: 8/21/2013
I believe that the technical content of this document is complete and stable
and ready to move forward.
As a JOSE working group member and editor, I am aware of editorial changes
being requested to be made to the JWS and JWE documents that could change some
of the terminology used by JWT - in p
1) As a JWT is always an instance of JWE or JWS, I am not sure why there
is a need for the the materials found in Section 5, para 1 (these are
also found in the JWE and JWS draft specifications). It could simply be
removed from the draft.
2) Why do we need both a "typ" claim and a "typ" header
13 matches
Mail list logo
