Hi Justin,
Well, I spent ~20min to read over this pair of drafts (association +
software_statement). I have to say that in isolation, I find this approach
quite reasonable. In particular:
1. This approach does *not* require both a bearer token and
software_statement for the registration step. The
I think for the client types, the trick is to try to make it restrictive enough
so there's no second-guessing the client developer has to do about what SPs
will accept. The line I was drawing was for implicit/javascript clients in the
current draft.
We could open it to a simple decision for th
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-11-01, at 1:17 PM, Hannes Tschofenig wrote:
> 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
Hi Mike, Hi all,
I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out
whether I would be able to produce an interoperable implementation from
this document.
A few minor things came to my mind:
Section 3:
You write:
"
1. The JWT MUST contain an "iss" (issuer) claim th
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 be
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
wrote:
Hi Phil, Hi Tony, Hi all,
regarding this document I believe there are the followi
Thank you for your review, Brian.
Am 01.11.13 20:53, schrieb Brian Campbell:
I just saw
http://www.ietf.org/mail-archive/web/oauth/current/msg12218.html from
Hannes noting reviews on draft-ietf-oauth-json-web-token and was
surprised that mine wasn't included. So I went looking for it and
apparen
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.
See below...
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-11-01, at 12:13 PM, Hannes Tschofenig 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
I just saw http://www.ietf.org/mail-archive/web/oauth/current/msg12218.htmlfrom
Hannes noting reviews on draft-ietf-oauth-json-web-token and was
surprised that mine wasn't included. So I went looking for it and
apparently I didn't actually send it to the list. But I did find it and am
including wha
Hi Mike, Hi all,
I was just trying to find out whether version -12 of the JWT spec
addresses prior comments and the diff version of the document does not
really give that indication. To me it seems that version -12 of the
document was published to update -11 in an attempt to create an
alignme
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
als
I would like to encourage people to read the client association draft before
monday. http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt
and the related
http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt
Most of the draft just focuses on background and taxon
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
Hi John,
thanks for the super-quick response.
Am 01.11.13 19:18, schrieb John Bradley:
The client_id would continue to be opaque to the client as it is now.
The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
provide integrity if it is using a symmetric key (probably the
simple
The client_id would continue to be opaque to the client as it is now. The AS
can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and provide integrity
if it is using a symmetric key (probably the simplest thing if we are talking
about a single registration endpoint paired with a single AS)
Hi John,
Hi all,
I read your document and here a few remarks.
In the dynamic client registration conference calls the topic of the
stateless client was raised since there was the argument in the air that
the current OAuth 2.0 RFC requires clients to be stateless due to the
nature of the clien
17 matches
Mail list logo
