ea since we don't deal with
other OAuth management issues
-Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration
t; On 08/27/2013 01:20 PM, Anthony Nadalin wrote:
>>> Thanks for splitting this and making it simple.
>>>
>>> It's unclear if the server must send the metadata back in same
>>> form/order/ as sent, that is, does client expect to get back only
>>&
e APPS area since we don't deal
>> with other OAuth management issues
>>
>> -Original Message-----
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
>> Richer, Justin P.
>> Sent: Tuesday, August 27, 2013 7:06 AM
>> To:
2013 7:06 AM
> To: oauth mailing list
> Subject: [OAUTH-WG] Refactoring Dynamic Registration
>
> After last week's design team call, at Derek's suggestion, I took time today
> to refactor the Dynamic Registration draft into two pieces: "core" and
> "m
pect to get back only
what was sent with what server values will be or can client deal with
defaults that the sever sets
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing l
esday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration
After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic
Registration draft into two pieces: "core" and "manage
g] On Behalf Of
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration
After last week's design team call, at Derek's suggestion, I took time today to
refactor the Dynamic Registration draft into two pie
ar if the server must send the metadata back in same
>> form/order/ as sent, that is, does client expect to get back only
>> what was sent with what server values will be or can client deal with
>> defaults that the sever sets
>>
>> -Original Message-
>>
ame
form/order/ as sent, that is, does client expect to get back only what
was sent with what server values will be or can client deal with
defaults that the sever sets
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Tuesd
; defaults that the sever sets
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Richer, Justin P.
> Sent: Tuesday, August 27, 2013 7:06 AM
> To: oauth mailing list
> Subject: [OAUTH-WG] Refactoring Dynamic Registration
in P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration
After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic
Registration draft into two pieces: "core" and "
ginal Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration
After last week's design team call, at Derek's suggestion, I too
After last week's design team call, at Derek's suggestion, I took time today to
refactor the Dynamic Registration draft into two pieces: "core" and
"management". The former contains the definition of the Registration Endpoint
and the semantics surrounding that, the latter contains the Client
Co
13 matches
Mail list logo
