RE: Oauth blog post

["Worley, Dale R (Dale)" <[e-mail]>]

> From: Yaron Sheffer [[e-mail]]
> 
> [...] but what I'm reading is three concrete statements that IETF
> members can respond to, and (if we accept them as true) consider how
> to address in the future:
> 
> - A Web-focused protocol was forced to adopt enterprise use cases.
> [...]

My first impulse is to say, yes, protocols that solve "enterprise"
problems are a lot more difficult than ones that solve individual-user
problems.  One that showed up in my field (SIP) was the concept of
"securely" identifying the party you have called.  If I normally call
John Smith at my bank to do business, and if John Smith is replaced at
his job by another person, and I call "John Smith at the bank", should
I authenticate that I am talking to John Smith, or should I
authenticate that I am talking to the person who holds the job at the
bank that John Smith used to have?

> Tim bray writes in an essay:
> 
> Enterpriseyness · One of Eran’s central gripes is the immense
> difficulty of knitting "Enterprise" requirements into OAuth — or any
> other standards work, for that matter. He’s right. The Web use cases
> may not be easy to solve, but they’re easy to understand. [...]
> 
> On the other hand, whenever I get into a conversation with someone on
> the Enterprise side, even when I think I understand the problem
> domain, I lose the plot, and fast. The requirements these people claim
> to have around both authentication and authorization are so arcane and
> subtle and legacy-laden that you have to be a full-time professional
> to even understand them.

Which reminds me that large organizations have the problem that every
new activity is necessarily a small change on a monstrous base of
current systems, and has to work harmoniously with them.  As someone
once observed:

> The reason God could create the Universe in six days is that He didn't
> have to make it upward compatible.

Dale