Re: [OAUTH-WG] draft-hunt-oauth-software-statement-00

Hi Phil,

thanks for the quick response.

Am 01.11.13 20:54, schrieb Phil Hunt:
> See below... Phil
>
> @independentid www.independentid.com phil.hunt@oracle.com
>
> On 2013-11-01, at 12:13 PM, Hannes Tschofenig
> <hannes.tschofenig@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
>