Authz server and resource server need to agree on a token format. The client
never needs to interpret the token content. Since we are talking about clients,
where is the connection?
regards,
Torsten.
Phil Hunt schrieb:
>I think many of the parameters in dyn reg need to be specified in the
>
ussions will only lead
>> to better specifications that folks can actually implement and use.
>>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Justin Richer
>> Sent: Wednesday, August 28, 2013 8:42 AM
&g
, August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details
Except for the cases where you want step 1 to happen in band. To me, that is
a vitally and fundamentally important use case
I think many of the parameters in dyn reg need to be specified in the statement
-- the main change is we're moving dyn reg parameters into the statement and
locking them down between instances. It keeps hackers from changing individual
instances and it minimizes state in per instance registrati
Behalf Of *George Fletcher
*Sent:* Wednesday, August 28, 2013 9:21 AM
*To:* Phil Hunt
*Cc:* oauth mailing list
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call:
Wed 28 Aug, 2pm PDT: Conference Bridge Details
On 8/28/13 12:02 PM, Phil Hunt wrote:
Please define the
ot want
>>>>> require client-secret, we already have that mess today with OAuth and
>>>>> trying not to continue the proliferation, we solve this today with our
>>>>> STS and assertion swaps/transformations, it scales, performs and we
>>>>> d
You can pass anything as a client_id. It just has to be accepted. That's the
point of us writing a draft here isn't it?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-08-28, at 9:45 AM, John Bradley wrote:
> That is my concern as well, sending an assertion to th
013 9:21 AM
*To:* Phil Hunt
*Cc:* oauth mailing list
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call:
Wed 28 Aug, 2pm PDT: Conference Bridge Details
On 8/28/13 12:02 PM, Phil Hunt wrote:
Please define the all in one case. I think this is the edge case and is in
fact rare.
That is my concern as well, sending an assertion to the authorization endpoint
requires a extension of OAuth to add another parameter or placing it in the
client_id which you can do now with the dynamic reg spec if the AS wants to.
Holding up client registration for something that will require
>>> require client-secret, we already have that mess today with OAuth and
>>>> trying not to continue the proliferation, we solve this today with our
>>>> STS and assertion swaps/transformations, it scales, performs and we
>>>> don’t have the management d
gt; don’t have the management debacle this specification creates
>>>
>>> *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
>>> Behalf Of *George Fletcher
>>> *Sent:* Wednesday, August 28, 2013 9:21 AM
>>> *To:* Phil Hunt
>>> *Cc
have the management debacle this specification creates
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *George Fletcher
*Sent:* Wednesday, August 28, 2013 9:21 AM
*To:* Phil Hunt
*Cc:* oauth mailing list
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conferen
The initial_access_token doesn't assume that it's from the local domain.
It merely assumes that the authorization server accepts the token, which
would be true in the UMA case due to the federation. It could also be
the exact same kinds of mechanisms that the software statement would use
to ach
un...@ietf.org] *On
Behalf Of *George Fletcher
*Sent:* Wednesday, August 28, 2013 9:21 AM
*To:* Phil Hunt
*Cc:* oauth mailing list
*Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call:
Wed 28 Aug, 2pm PDT: Conference Bridge Details
On 8/28/13 12:02 PM, Phil Hunt wrote:
Pleas
George,
It would be reasonable for a client to submit an assertion, and obtain its own
client assertion in return. This is very close to what is happening per 2.1,
2.2 of http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06
In this case, the Software Statement is an authorization that is
On 28/08/13 17:20, Phil Hunt wrote:
This is the key problem with dyn reg.
You have to recognize software as distinct entities shared by clients as
instances. Statements can be by a developer, an organization or an api owner
that approves clients in the same way google or facebook does today.
George
That case can be solved with a simple assertion swap. We just have to profile
it.
Phil
On 2013-08-28, at 9:20, George Fletcher wrote:
>
> On 8/28/13 12:02 PM, Phil Hunt wrote:
>> Please define the all in one case. I think this is the edge case and is in
>> fact rare.
>>
>> I agree
This is the key problem with dyn reg.
You have to recognize software as distinct entities shared by clients as
instances. Statements can be by a developer, an organization or an api owner
that approves clients in the same way google or facebook does today.
The approval happens once per client
I set up an auth server to protect my API, my users download a piece of
software that speaks the API to access their data. Where is my server
supposed to get the list of "approved" software classes from? Are you
assuming a central registry per API? Or is it going to be
provider-specific? If the
M
To: Anthony Nadalin
Cc: Phil Hunt; oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details
Except that folks are already actually implementing and using the spec, and
that all of the discussions around different s
Please define the all in one case. I think this is the edge case and is in fact
rare.
I agree, in many cases step 1 can be made by simply approving a class of
software. But then step 2 is simplified.
Dyn reg assumes every registration of an instance is unique which too me is a
very extreme p
:51 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details
Except that folks are already actually implementing and using the spec, and
that all of the discussions around different
sday, August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details
Except for the cases where you want step 1 to happen in band. To me, that is a vitally and
fundamentally importan
August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details
Except for the cases where you want step 1 to happen in band. To me, that is a
vitally and fundamentally importan
Except for the cases where you want step 1 to happen in band. To me,
that is a vitally and fundamentally important use case that we can't
disregard, and we must have a solution that can accommodate that. The
notions of "publisher" and "product" fade very quickly once you get
outside of the soft
Sorry. I meant also to say i think there are 2 registration steps.
1. Software registration/approval. This often happens out of band. But in this
step policy is defined that approves software for use. Many of the reg params
are known here.
Federation techniques come into play as trust approva
I have a conflict I cannot get out of for 2pacific.
I think a certificate based approach is going to simplify exchanges in all
cases. I encourage the group to explore the concept on the call.
I am not sure breaking dyn reg up helps. It creates yet another option. I would
like to explore how f
Here are the conference bridge / Webex details for the call today.
We are going to complete the use case discussions from last time (Phil wasn't
able to walk through all slides). Justin was also able to work out a strawman
proposal based on the discussions last week and we will have a look at it
28 matches
Mail list logo
