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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 20:13:51 +0100

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?

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?

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).

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.

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Nov 2013 12:54:48 -0700

See below...
Phil

@independentid
www.independentid.com
[email-masked]

On 2013-11-01, at 12:13 PM, Hannes Tschofenig <[email-masked]> wrote:

> 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).
> 
> 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. 
> 
> c) Is the proposed approach for conveying the software statement acceptable for the group?

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.
> * 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

> 
> Ciao
> Hannes
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 21:17:47 +0100

Hi Phil,

thanks for the quick response.

Am 01.11.13 20:54, schrieb Phil Hunt:
> See below... Phil
>
> @independentid www.independentid.com [email-masked]
>
> 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?
>

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.

>> 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.

>> * 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 [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Nov 2013 14:24:50 -0700

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-11-01, at 1:17 PM, Hannes Tschofenig <[email-masked]> wrote:

> 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.

Hmmm…. not sure what granularity you are after.  I am just describing what is essentially a "federated" model for registration that works for developers who have no prior relationship with the service providers that deploy a particular API.  Nothing more.

One way to look at this is that Software Statements preserve the current methodology of the client developer registering with the developer registration service for an API -- usually that would be the organization that controls/revises/updates the API definition.  In commercial APIs that would be the vendor, in open APIs, it would be the consortium or the open source project.  In OpenID Connect for example, it could be the OIDF or someone like the OIX since OIX is helping to vet/whitelist IDPs.

Finally, if no organization is available to provide the developer software statement, the developer can always self-assert. In a sense this becomes similar to dyn reg now.  Except with one major difference.  All copies of the developer's client will still use the same assertion and the registration profile is "locked".  

You could even go to per instance assertions where the developer could decide to have the client generate on the fly if their use case really does demand completely different registration per client instance -- I've yet to see a valid use case, but this would still be possible.

IOW -- this is no different from other federation models where AS service providers decide to trust different assertion "roots" or specific assertions as needed.  A well worn model.

===>  Any lifecycle model is possible!
> 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.

My understanding is that dyn reg has these attributes as well (so they are no longer new).  It may be that software statement's attributes need to be updated to reflect the current dyn reg phrasing.
> Thanks; that might be useful. I personally don't have a preference here but getting feedback from the group would be good.
> 
> 
>>>