[OpenID] DISCUSSION relating to OpenID Discovery 2.1

David Fuelling sappenin at gmail.com
Wed Dec 31 15:26:08 UTC 2008


On Tue, Dec 30, 2008 at 7:00 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  I gave up half way through my careful reply, as it was approaching
> formatting-incomprehensible …to the poor reader trying follow it, point by
> inset counterpoint.
>

Yes, I encountered the same thing in my responses.  :)

>
>
> 1.is metadata mandatory (XRDS or HTML)? Id claim no, by design concept. My
> proffer of proof is an example: the op-initiated unsolicited assertion
> (which has no openid-classical user input stage, and thus no discovery,
> SAML1-like). The nature of AX update is secondary proffer.
>
Correct me if I'm wrong, but in your proffer case, an unsolicited assertion
will still have an OpenID Identifier, correct?  Before accepting such an
assertion, the RP should verify that the OP sending the assertion is the
entity who can actually make that assertion.  To do that, the RP must either
perform 7.3 "discovery" on the claimed identifier (just for validation
purposes), or the RP must validate the Claimed Identifier in some other way
(referencing my previous thread, I would argue this "some other way" must
always have its root in 7.3 Discovery -- though it's really just verfication
in this scenario).

So, the question becomes: How does an RP figure out who can (and who cannot)
make an assertion on behalf of a given Claimed Identifier?

Are you saying that the manner in which this is done is merely "SUGGESTED"
by the spec, but that RP's can pretty much choose to figure this out any old
way they want?  See my response to your #5 below for why this is such a big
deal to me.


>
>
> 2. Even if metadata via openid discovery is mandatory for an act of
> interworking, it's not "intended" (read "conceived") to serve as a control
> framework (for authorization, privileges, permissions, contract bindings,…)
>
> I'm not sure you can separate the two -- If "metadata via OpenId Discovery"
is mandatory, then it becomes an authority over the Claimed Identifier
(regardless of intent).

>
>
> 3. Some folk evidently see a cousin of the openid2 XRI name servers (XDI)
> as the infrastructure in openid's future that is intended to play the role
> (one day) of a fully-fledged, very well-designed authority-based distributed
> control framework -representing the large-N OP->SP trust models, the
> attribute contracts per SP webapp, the EDI-style "interworking agreement",
> the contract arrangements, the legal terms and conditions… However, XDI is
> hardly established practice in OpenID world. I'm not sure if there even
> exists a single production usage! It's obviously R&D. (if anyone can counter
> this, let me know; I WANT to try it out, to see if/when it will be viable
> for business use.) XDI may not never come to be adopted in the "finalized
> specs", if Nat's alternative "CX" regime supplants it (or the highly
> practical internet-based MPLS-VPNs (per Rapattoni) become the norm for
> wire-speed trust networking).
>
>
>
>
>
> 4. you say "To my way of thinking, this should be clarified in OpenID auth
> 2.1 -- at the least, if an RP is going to use some non-7.3 mechanism to get
> an OP Endpoint URL, then that "mechanism" MUST be populated via traditional
> Discovery. "
>
>
>
> Why! ..is it so important to you? This proposition essentially turns
> OpeniD2 into Shib. I might as well just use Shib, and get the assurance of
> properly specified types expressed in a decent type language. OpenId has
> really intellectually done nothing if all it does it replace XML with
> name-value pairs, and SAML metadata with XRDS, and one metadata-based
> control model for protocol orchestration…with another.
>
>
>
Yes, it's very important -- see my response to your #5.


> But at least you are being direct and honest about the desire. The
> "advanced" notions that folks settled on 2 years ago clearly need revisiting
> – to see which work, which got adopted  in practice, which should get
> dumped, and which get another  try as they are obviously still
> works-in-progress.
>
>
>
> 5. I suspect, while focusing on points about
> metadata/authorization/control, we are really tangentially addressing the
> bugbear topic of all websso schemes: repurposing, and the desire of the
> asserting party to  control who can repurpose an assertion (or reuse a AX
> response). And of course, that goes  to the heart of the current social
> debate on who controls a users data, the user or the TTP. Once user's own
> their data, lots of very traditional business models go out of the door.
> Lots of governance models also get left behind. Ensuring that such
> "old-model" controls can be overlaid on such as websso (to control
> downstream actors) has to be expected. So far, the  openid project has not
> been a foil for shib-like infrastructure governance models (though one can
> and should overlay those constructs on OpenID, OPTIONALLY, per trust
> network)
>
>
>
Here's why this is so important to me:

   1. *User Centric Identity
   *Ideally, I want the user to be in control of their identity, including
   which OP asserts for them, and also including what an RP can do with a
   user's identity.  Mandatory 7.3 Discovery provides a framework to enforce
   these types of things (see my other
proposals<http://wiki.openid.net/OpenID-Discovery#IIInbspIssues/IdeasforDiscussion>here
relating to discovery).  If 7.3 Discovery is not mandatory, then RP's
   can ignore the XRDS stuff (theoretically) and do whatever they want (i.e.,
   ignore the wishes of a user).

   2. *RP Confusion*
   If RP's are not required to do 7.3 discovery (at some point), then where
   does authority come from?  One might say, "there is no authority", but then
   the notion of an assertion becomes very dilluted -- gmail.com might make
   an assertion on my sappenin.com OpenID Identifier, and how will an RP
   know to accept or deny that assertion?  Unless I'm missing something, making
   7.3 Discovery optional seems to remove the main foundation on which OpenID
   stands, thus confining OpenID to a world of pre-defined assertion
   relationships (i.e., google and yahoo meet in an offline room, agree to
   accept assertions from each other only) -- there's nothing "Open" about
   that.  It should be renamed "contractual id", and we already have a
   world-wide deployed framework for this type of one-to-one credentials
   arrangement -- it's called a username/password.

   3. *End-User Confusion
   *With 7.3 Discovery being optional, how should users define their OP?
   They can't rely on 7.3 mechanisms with any degree of certainty, since
   there's no requirement to respect their 7.3 metadata (in this hypothetical
   world).


Ignoring for a moment you assertion that "This proposition essentially turns
OpeniD2 into Shib", I'll reverse the question somewhat and pose it back to
you:  What's wrong with OpenID mandating an authority scheme (i.e., a way to
specify that a particular OP is authoritative for a particular Claimed
Identifier) via 7.3 Discovery?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081231/d88709ea/attachment-0002.htm>


More information about the specs mailing list