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 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.
> Even at this level, site security policies will simply override
whatever is stated in the specification and choose one type only.
Yes, but those policies will be affected by what's available in
the running code. I'd like if what's available was known when
the coder says "we implement RFC <foo>"
Having multiple MTIs, suggests choice and that causes other problems. What
happens when a client wants to use a bearer token over an unprotected
connection? How does the client discover what can be used and when?
Having no MTI causes identical problems.
The approach we have now where the Token specification defines interop
requirements and a profile for use with OAuth2 seems to be a good way to go.
We disagree about that I guess. To me it seems a peculiar way to go
unless one assumes that coders write code that's specific to a specific
service provider.
S.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-12-01, at 1:25 PM, Stephen Farrell wrote:
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 favour that outcome and really
care about that need to speak up on the list, since the list
consensus trumps the sense of the room in the chairs' evaluation
of the WG consensus.
Second, at the meeting I said that I'd like to see either MAC or
bearer picked as MTI, and if not, that I want the draft to say
why its ok to have no MTI token type. So the WG either need to
pick one, or else explicitly and convincingly justify not
picking one. That's the "firm" AD position to which Barry
referred. (I didn't properly call out the "if not" part of
that in my AD review, sorry.)
My own argument for picking one is simple: if every relevant
piece of code has to know how to handle one then it becomes
easier to get interop. If everyone decides for themselves
then interop is less likely since there are currently two
choices and may be more in future.
I do realise that the background here and current practice
is that code tends to be written that is specific to a
resource server (or however that's best phrased) but that's
maybe where the IETF differs from the community that produced
OAuth - here we want two independent implementers who've
never talked to produce code that interops even so.
I also realise that that's not the full story for getting
interop with OAuth and that more is needed. However, this
aspect is otherwise fully specified and so I don't buy the
argument that this isn't worth doing just because we don't
have the full registration story etc. figured out. If we don't
sort this out now, then later specs will have to update
this one in this respect. possibly making existing code
"non-compliant" in some sense, so just going ahead and doing
it right now is better.
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.
Regards,
Stephen.
On 11/17/2011 08:28 AM, Barry Leiba wrote:
Stephen, as AD, brought up the question of mandatory-to-implement
token types, in the IETF 82 meeting. There was some extended
discussion on the point:
- Stephen is firm in his belief that it's necessary for
interoperability. He notes that mandatory to *implement* is not the
same as mandatory to *use*.
- Several participants believe that without a mechanism for requesting
or negotiating a token type, there is no value in having any type be
mandatory to implement.
Stephen is happy to continue the discussion on the list, and make his
point clear. In any case, there was clear consensus in the room that
we *should* specify a mandatory-to-implement type, and that that type
be bearer tokens. This would be specified in the base document, and
would make a normative reference from the base doc to the bearer token
doc.
We need to confirm that consensus on the mailing list, so this starts
the discussion. Let's work on resolving this over the next week or
so, and moving forward:
1. Should we specify some token type as mandatory to implement? Why
or why not (*briefly*)?
2. If we do specify one, which token type should it be?
Barry, as chair
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
