+1
Sent from my iPhone
On 2013-06-04, at 7:56 PM, George Fletcher wrote:
> +1 for leaving dyn reg as is and working on a profile that enables this more
> domain specific scenario. I agree with Phil and Justine that it's
> important... I just don't think it should be put in the core dyn reg sp
Amanda, thanks for the review -- comments inline.
On Jun 4, 2013, at 1:56 PM, "Anganes, Amanda L"
mailto:aanga...@mitre.org>> wrote:
[[Apologies if you receive this twice, I accidentally sent this from one of my
other email addresses this morning (Outlook seems to have been confused).]]
Hello,
That's correct, but they're all editorial (non-normative) in nature and
I've been in communication with the other editors as well.
Everyone is welcome to follow along with the editing process in github
if they like.
-- Justin
On 06/04/2013 02:43 PM, Phil Hunt wrote:
Those changes off git hu
Those changes off git hub have not been shared with the group and are not
necessarily approved.
Phil
On 2013-06-04, at 11:03, "Anganes, Amanda L" wrote:
> Note that this review applies to the latest spec edits from Justin's Github,
> which can be found here: https://github.com/jricher/oauth-
No problem, Georgia. :)
On 06/04/2013 02:10 PM, George Fletcher wrote:
Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry
Justin!
On 6/4/13 1:56 PM, George Fletcher wrote:
+1 for leaving dyn reg as is and working on a profile that enables
this more domain specific scenario.
+1
The fact that there has been so much discussion around this topic seems like a
clear indicator to me that the group needs to carefully and precisely figure
out the use cases and mechanisms needed to identify "application classes" or
"client instances" (or whatever they should be called), in
Argh! Typos (due to iPhone? no bad brain <-> hand connections). Sorry
Justin!
On 6/4/13 1:56 PM, George Fletcher wrote:
+1 for leaving dyn reg as is and working on a profile that enables
this more domain specific scenario. I agree with Phil and Justine that
it's important... I just don't think
Note that this review applies to the latest spec edits from Justin's Github,
which can be found here: https://github.com/jricher/oauth-spec. The –12
revision has not been published yet, but Justin asked me to review based off of
what was in the tracker, since it is more up-to-date.
--Amanda
Fr
+1 for leaving dyn reg as is and working on a profile that enables this
more domain specific scenario. I agree with Phil and Justine that it's
important... I just don't think it should be put in the core dyn reg spec.
Thanks,
George
On 6/4/13 12:45 PM, Justin Richer wrote:
I agree with the goa
[[Apologies if you receive this twice, I accidentally sent this from one of my
other email addresses this morning (Outlook seems to have been confused).]]
Hello,
I have reviewed the Dynamic Registration draft and offer some comments below:
After section 1.2, I suggest adding a flow diagram (sim
I agree with the goal of standardizing on identifying software
instances, but I think it's out of scope to do so inside of dynamic
registration when most dynamic registration use cases don't need it and
won't use it. I think that you've got to define discovery, assertion
contents, and a few oth
Re-send: my earlier mail seems to have gotten lost.
-Original Message-
From: Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, June 04, 2013 2:21 PM
To: 'OAuth@ietf.org'
Subject: Review of the Dynamic Registration Draft
Dear draft authors, Dear working group,
I read through the dynami
Dear draft authors, Dear working group,
I read through the dynamic registration draft and here a few observations I
have made:
* The 'Initial Access Token' is really more a developer identifier. If you give
it a different
name then it might be more intuitive for the reader since the current w
Yes. However the contents and format are out of scope.
Phil
On 2013-06-03, at 22:32, Torsten Lodderstedt wrote:
> Hi Phil,
>
> isn't the initial registration token such a credential, which allows to
> co-relate different instances of the same software?
>
> regards,
> Torsten.
>
>
>
>
14 matches
Mail list logo
