Hi Barry,
I agree with you generally, but just on one point...
On 02/18/2013 05:38 AM, Barry Leiba wrote:
That's why I say that as I see it, it's not an issue of MTI.
I do think there is an issue related to MTI that's affecting
the discussion. Clearing up that issue won't by itself solve
Barry,
I will point out that in RFC 6749 the Client is specificity not required to
understand the access token, it is required to understand the token_type in the
response from the authorization server in order to know how to present the
token to the RS.
Perhaps you were speaking
; oauth@ietf.org; oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan
OK, I have some time to respond to this on a real computer.
Let's look at the general mechanism that oauth provides, using one use case:
A client asks an authorization server for authorization to do
I'll get to John's message later, after I digest it more. I can reply to
this one now.
please explain how you and I can each write applications to that?
**
** **
You can write applications to that by having the profile chain end, and
with the contents of the Audience field being
.
-- Mike
From: barryleiba.mailing.li...@gmail.com
[mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba
Sent: Monday, February 18, 2013 10:37 AM
To: Mike Jones
Cc: Barry Leiba; oauth-cha...@tools.ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan
It seems like the scope of your criticism has more to do with RFC 6749
RFC 6750 overall, than the assertions drafts themselves.
No, and I'm sorry if it came across that way. I mentioned the token-type
issue only by way of background. As it happens, I do think it was a
mistake to publish
Dynamically declaring, in what sense? Where are those mechanisms
documented?
** **
Many of them are documented in draft-ietf-oauth-dyn-reg.
** **
One profile (an outer doll J) that enables fully interoperable
implementations is documented in draft-hardjono-oauth-umacore.
...
I do believe some face to face discussion amongst a smallerish group might
be valuable on this. I'll be in Orlando and plan on contributing to that as
much as I can. Thanks for organizing the lunch discussion Stephen.
I do feel that this conversation has strayed a bit and I'd like to clear up
one
Thanks Barry,
We had to partially roll our own registration spec because there was no common
one at the time. We did however partially base ours on the UMA one and now we
have sever groups working on
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ based on
implementation
Hi all,
The OAuth assertion document has received DISCUSSes as you can
see from the data tracker at [1]. I've been chatting with
the chairs and the ADs with those DISCUSSes in the last few
days.
The main concern is that these documents do not sufficiently
specify the functionality that is
In some off-list mail between Mike and I, he said:
Was TCP a bad idea because it didn't have MTI port numbers? Would
it have improved TCP to add an MTI port or two?
To which I responded:
Ports are MTI for TCP. [1] They are 16 bit values
with a well-defined test for equality and a little
, February 17, 2013 1:25 PM
To: Mike Jones
Cc: oauth@ietf.org; Barry Leiba; oauth-cha...@tools.ietf.org
Subject: Re: [OAUTH-WG] oauth assertions plan
Hi Mike,
On 02/17/2013 08:41 PM, Mike Jones wrote:
I've been thinking about Barry's DISCUSS for a bit. No one else has
responded yet, so I
OK, I have some time to respond to this on a real computer.
Let's look at the general mechanism that oauth provides, using one use case:
A client asks an authorization server for authorization to do something.
The authorization server responds with an authorization token, which
the client is
13 matches
Mail list logo
