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 nuisance sure. But it helps interop.
This smacks of truth by blatant assertion.
Of course. My 2 sentences have 10 words. Yours has 7. Neither can
really capture everything.
Nonetheless, picking between one of two things does help interop
IMO.
> 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 fair point if the MTI wasn't used.
While that might be true of MAC, I doubt it'd be true for bearer,
which is what seemed to be the thing folks in the room in Taipei
would pick, had they to pick.
So yes, your argument would be telling if the WG chose a rare
beast as the MTI thing.
I don't see what the big deal is about saying that discovery, etc, is
for a -bis release of this PS. That would take care of your problem of
reaching back into this PS to change just this part. And what are the
chances of not having a recycle anyway with any well-deployed PS?
Zero?
That's not a reason to not fix an easily fixable thing now though.
|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.
But that is exactly what's happening in the field.
To date yes. I would (perhaps naively) hope for that to get better
(by at least a bit) when we have an OAuth 2.0 RFC.
Cheers,
S.
Mike
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
