Hi Phil,
We definitely have to figure out how the differentiation is made so that
a developer (or someone who deploys the technology) understands the
scenario they are in and what the implications are. At the moment I
would struggle a bit.
Using examples is certainly a good idea, like you did below. There are,
however, quickly challenges. For example, in the JavaScript case below
you can imagine a developer of a smart phone app who uses JavaScript but
then packages the application (using PhoneGap), which makes it behave
very much like a native app.
And, as you say below, the notion of whether the endpoint is configured
upfront (during development time) or dynamically configured may not
necessarily matter.
It definitely makes sense to discuss this during the meeting and
real-world examples may help.
Ciao
Hannes
Am 01.11.13 20:56, schrieb Phil Hunt:
Hannes,
Great timing!
This is an aspect that I think deserves more discussion. One of the
challenges was to draw a clear line of distinction between transient
and dynamic.
Transient clients are really meant for javascript clients that decide
to connect to a particular end-point on the fly. Note you can still
have "static" javascript clients that are hard coded to connect and
have already received a client_id through an out-of-band process.
Phil
@independentid www.independentid.com phil.h...@oracle.com
On 2013-11-01, at 12:01 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net> wrote:
Hi Phil, Hi Tony, Hi all,
I re-read the document and I believe the most important concept it
introduces is the classification of different associations, namely
into 'static', 'dynamic', and 'transient'. This is certainly
something worthwhile to discuss during the meeting and to ensure
that it is well understood, and that there are only these three
classes (rather than two or four).
The description in the introduction makes the differentiation
between the three concepts mostly based on how the endpoints are
configured in the application.
With the static association the endpoint is hard-coded into the
software during the development time. It cannot be changed. With
the two other cases the endpoint can be changed. As such, the
difference between the 'dynamic', and 'transient' association seems
to be in the terms of how long the lifetime of the association.
Now, what exactly is the lifetime of an association? Is the
lifetime of the association understood as the lifetime of the
configured endpoint identifier?
Then, when I re-read the text in Section 1 again then I suddenly
get the impression that the lifetime of the association actually
does not matter but instead the difference is rather whether the
client is public or confidential. Is that true?
If it isn't true that this is the feature that makes the
distinction between 'dynamic', and 'transient' then the notion of
"public" vs. "confidential" client isn't too important for the rest
of the document.
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
