The problem is that token type AWESOME may have different mechanics for
submission. The client has to know how to use it. I do agree we have a
disconnect here, and that what we have right now leans completely on "reading
the service documentation" for the Auth and RP endpoints you want to use.
>> So an MTI token type + no client preference is equivalent to there
>> only existing one token type.
>
> Maybe.
>
> However, no MTI token type + no client preference = no interop.
I think this exchange, coupled with what you Stephen said in Taipei
(noting that "mandatory to implement" doesn't me
On Thu, Dec 1, 2011 at 6:27 PM, Stephen Farrell
wrote:
> On 12/02/2011 02:14 AM, Michael D Adams wrote:
>> Suppose an authorization server implements OAuth2 and has some
>> requirement that the MTI token type doesn't provide (as William Mills
>> suggested), so the server implements token type AWES
On 12/01/2011 06:22 PM, Stephen Farrell wrote:
> If something is required to
be implemented but is unused -- which will happen if the profile
chosen by the SDK doesn't need the required one -- you're not going
to get better interoperability, you're just going to get untested code.
That'd be a
Hiya,
On 12/02/2011 02:14 AM, Michael D Adams wrote:
On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
wrote:
On 12/02/2011 01:38 AM, Michael D Adams wrote:
So an MTI token type + no client preference is equivalent to there
only existing one token type.
Maybe.
However, no MTI token type +
Hi Mike,
On 12/02/2011 01:35 AM, Michael Thomas wrote:
On 12/01/2011 05:23 PM, Stephen Farrell wrote:
E.g. MAC tokens work well for non-TLS protected resources. Bearer
tokens in contrast are easier to use, but require TLS protected
service to avoid theft-of-credential.
So picking is a nuisan
On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell
wrote:
> On 12/02/2011 01:38 AM, Michael D Adams wrote:
>> So an MTI token type + no client preference is equivalent to there
>> only existing one token type.
>
> Maybe.
>
> However, no MTI token type + no client preference = no interop.
>
> So I don
On 12/02/2011 01:50 AM, William Mills wrote:
If we MTI a "weaker" token type (arguably Bearer falls here) that means
the spec will be inappropriate in higher security requirement situations, those
folks walk away.
Disagree. People who need more can specify more.
The base spec not having an
If we MTI a "weaker" token type (arguably Bearer falls here) that means
the spec will be inappropriate in higher security requirement situations, those
folks walk away.
If we MTI something like SAML it makes the folks that want a light weight
Bearer token solution walk away.
Hiya,
On 12/02/2011 01:38 AM, Michael D Adams wrote:
I echo Justin Richer's comments.
On Thu, Nov 17, 2011 at 12:28 AM, Barry Leiba wrote:
1. Should we specify some token type as mandatory to implement? Why
or why not (*briefly*)?
No. There's no mechanism in the spec for clients to reque
I echo Justin Richer's comments.
On Thu, Nov 17, 2011 at 12:28 AM, Barry Leiba wrote:
> 1. Should we specify some token type as mandatory to implement? Why
> or why not (*briefly*)?
No. There's no mechanism in the spec for clients to request a
particular token type, so there's no opportunity f
On 12/01/2011 05:23 PM, Stephen Farrell wrote:
E.g. MAC tokens work well for non-TLS protected resources. Bearer tokens in
contrast are easier to use, but require TLS protected service to avoid
theft-of-credential.
So picking is a nuisance sure. But it helps interop.
This smacks of truth b
On 12/02/2011 12:23 AM, Phil Hunt wrote:
Because different token types have distinct advantages in different scenarios,
choosing a single MTI would be difficult.
I just don't get that. Why is it somehow difficult to pick one
but at the same time easy to implement any?
E.g. MAC tokens work
On 12/01/2011 11:37 PM, William Mills wrote:
Re: "So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices
available."
We don't have discovery done (enough) yet to lean on it in the core spec, but
if we did I'd be in favor
Because different token types have distinct advantages in different scenarios,
choosing a single MTI would be difficult. E.g. MAC tokens work well for non-TLS
protected resources. Bearer tokens in contrast are easier to use, but require
TLS protected service to avoid theft-of-credential. Even a
Re: "So, pick one (my strong personal preference) or establish and
document why you're not picking one seem to me to be the choices
available."
We don't have discovery done (enough) yet to lean on it in the core spec, but
if we did I'd be in favor of something that says that you must implement ei
+1 to dropping cookies.
On 11/19/2011 10:33 AM, Eran Hammer-Lahav wrote:
I would like to drop the cookies support defined in the MAC document
due to lack of interest from the browser vendors. At this point it is
most likely going to be an unimplemented proposal. If there is
interest in the f
Barry, all,
First, apologies for being so slow responding, various
travels got in the way. I hope we can quickly resolve this now.
Bit of process first: at the meeting we discussed this and at the
end of that discussion, there were quite a few more folks for the
"pick one" position. People who
On 12/1/11 1:57 PM, Stephen Farrell wrote:
>
>
> On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
>> On 12/1/11 1:09 PM, Rob Richards wrote:
>>> On 11/28/11 10:39 PM, Barry Leiba wrote:
> The OAuth base doc refers in two places to TLS versions (with the same
> text in both places:
>
>
On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
On 12/1/11 1:09 PM, Rob Richards wrote:
On 11/28/11 10:39 PM, Barry Leiba wrote:
The OAuth base doc refers in two places to TLS versions (with the same
text in both places:
OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
On 12/1/11 1:09 PM, Rob Richards wrote:
> On 11/28/11 10:39 PM, Barry Leiba wrote:
>>> The OAuth base doc refers in two places to TLS versions (with the same
>>> text in both places:
>>>
>>> OLD
>>> The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
>>> support TLS 1.2 ([RFC5246]) an
On 11/28/11 10:39 PM, Barry Leiba wrote:
The OAuth base doc refers in two places to TLS versions (with the same
text in both places:
OLD
The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
support additional transport
Folks,
FYI there will be a free UMA webinar on December 14 (Wed) at 10AM-Pacific. It
will include some info/demo by implementers.
The registration link is at the following site:
http://kantarainitiative.org/confluence/display/uma/Home
--
UMA Webinar on Wedn
23 matches
Mail list logo
