Hi Phil,
thanks for the quick response.
Am 01.11.13 20:54, schrieb Phil Hunt:
See below... Phil
@independentid www.independentid.com phil.h...@oracle.com
On 2013-11-01, at 12:13 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net> wrote:
Hi Phil, Hi Tony, Hi all,
regarding this document I believe there are the following questions
the group may want to think about:
a) Is the lifecycle of software development (Figure 1) common
accross several companies?
We are trying to be generic. What we are trying to do is take the old
model where a developer would register with a Facebook, a Google,
whatever and apply it to what happens to open source API and
commercial API scenarios where software is deployed in many locations
(not just a single cloud provider).
Certainly makes sense. I am just saying that it would be good if there
are others in the group who say that the described model lines up with
their practices. You never know but their practices may actually be
different.
b) The document defines a number of attributes. Are those
attributes also used in other deployments? Is their semantic
clearly defined so that meaningful actions can be taken when
receiving those?
The attributes come from Dynamic Registration. Only thing new here
is software_id and software_version.
I didn't realize that. Maybe that's worthwhile to highlight.
So, the question would then be to the group whether the two newly
defined attributes are sufficient and well-defined. The description was
good for me.
c) Is the proposed approach for conveying the software statement
acceptable for the group? (currently the information is conveyed as
a bearer token encoded as JWT).
John Bradley's JWT token is similar, but I think they have different
characteristics in the way they are used. I'd like to here John
present this at the meeting before I attempt to try and compare them.
This is something I'd like to work on together.
Thanks; that might be useful. I personally don't have a preference here
but getting feedback from the group would be good.
What would be good to have is two things:
* Examples
* Text that describes what decisions can be made by the
introduction of the software assertions. This text could go into
the introduction to provide a motivation about why to use it.
I am open to a lot of change her. If anything, my feeling is that if
anything we should cut the drafts back down to the raw normative
text. It is my feeling there is too much explanatory text that
drives the perception that the proposal is complex. Yet this boils
down to 3 methods:
Static - do what you are doing now if that works. Dynamic - Swap a
software statement (shared by all instances of the same app) for an
individual client assertion (assertion swap) Transient - just pass
your software_id (or maybe it should be software statement) as you
client_id
I like that short summary. That should be something for the intro
Ciao
Hannes
Ciao Hannes _______________________________________________ OAuth
mailing list OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
