| [higgins-dev] Notes from Higgins Developers call on Thursday, April 9. |
|
Higgins
dev call – April 9, 2009 Attendees *
Brian Carroll - Serena *
Andy Hodgkinson - Novell *
Drummond Reed - Cordance *
Mary Ruddy - Meristic * Markus
Sabedello - Parity * Paul
Trevithick - Parity *
Brian Walker - Parity *John Logistics
4.
[Paul, JohnB] Relationship Brokering With R-Cards (held over)
·
[Mary]
John would you like to kick off this topic? ·
[John]
It’s a good thing. Over to Paul. ·
[Paul]
I’m on the road now, so I will have to wing this. There is a link in the
agenda. ·
[Paul]
An r-card is a managed card. It is a superset. It has one extra piece of
information - a resource UDI defined by the UDI spec. It is a grab bag set of
ways to refer to an item. You’ve get got this card and you are a selector
or something that asked for the information. We are trying to track what
Drummond is doing with XRD, but for various reasons you might want to have this
discovery private. We can return the meta data around the UDI end point, as a
value of one of the claims on the managed card. The details of which I’m
still waiting for John to review, the flavors some of which are more chatty
than others. What they want to be able to do is discover enough to resolve it
and authenticate to the r-card data. That wiki page needs a lot of work and
attention. It describes how a person can share that r-card with another party
using standard attribute exchange and now the RP can discover how to resolve
that UDI modulo the access control policy. ·
[John]
One of the things that handling the discovery document back privately lets us
do is… ·
[Paul]
Beautiful example, we should add it to the wiki page. ·
[Paul]
Calling it r-card relationship brokering is covering a number of possible sub
use cases. Combing a lot of what you have done. Drummond, it may well use
XRI, XRD. It builds on everything we’ve got and defines a user
experience for how an RP ask for these claims.. It is very general purpose.
I’m hoping we as a community can refine the design of it and implement
it. Many of the building blocks are already implemented in Higgins. ·
[Markus]
When the selector wants to resolve it, the selector also gets the resource UDI
from the STS? ·
[Paul]
The resource UDI would be in the r-card itself. The selector can read that
value directly. Depending on what John comes up with, the end point, the
identity data service if it resources an oAuth , etc access token. The selector
may well have to do that. ·
[John]
There is the potential for embedding other access credentials in the r-card.
You could put the XRD inside the card. ·
[Paul]
There might be use cases for doing that. So John needs to work through that.
He and other folks. ·
[John]
You may not always want the selector to be able to access the service without
their intervention. ·
[Paul]
So the answer depends. So we need a number of possible flows. ·
[Paul]
So that was an overview Mary. ·
[Markus]
Can you say that in order to access part of a context service you need
an… ·
[John]
Portable contacts is a oAuth secured service, so if you put that you would need
to put the persistent token in and it would switch it for a session token ·
[Markus]
So the token from a Higgins perspective would be a kind of authentication
materials. ·
[John]
The output of a private UDI resolution. ·
[John]
The private one is only happening. ·
[Drummond]
The private version is push, the public version is pull. ·
[John]
Until there is security around the pull version, you can’t really put
access token in it. ·
[Drummond]
We are stretching the term resolution here. The recipient to whom you are granting
access you are sending the XRD in a claim. ·
[John]
If the XRD has multiple services it may help indicate the service being used.
If the reliant parity’s security policy says give me a UDI claim and the
value of the UDI claim is an XRD that has all that it needs that could work. ·
[Markus]
Can you consider the XRD a kind of UDI? ·
[John]
Right, that is what I was thinking.. ·
[Markus]
It is similar to what we were thinking with ID-WSF. ·
[John]
Essentially the RP doesn’t know what kind of relationship it wants. ·
[Paul]
So we are using r-cards to broker. ·
[John]
Yes to broker relationships. ·
[Paul]
Do you have a problem with what John and Markus are saying? ·
[Drummond]
Semantically we might be overloading it. It might be simpler to keep UDI as we
have been defining it. In the claim, that is what could be
expanded…discovery meta data, you can… ·
[John]
There is no way to give the UDI easily to a standard RP except as a value of a
claim. ·
[John]
Perhaps I want to give ….. ·
[John]
Is that complexity necessary? Putting the XDI endpoint in the XRD? ·
[Drummond]
If you need to use the private options you need to hand the credentials over in
this blob. If the endpoint speaks XDI, it is likely you can give it an XDI. A
push option of moving that data is a classic example of XDI anyway. ·
[John]
There are conceptually some issues with not knowing who you are sending
the… ·
[John]
Concept of assigning an identity .. the assumption is that it already has an
identity. ·
[Drummond]
It is not a strong enough use case., I’m not worried about supporting
that. We are looking to support EPR’s and XRD. ·
[John]
I would argue event the EPR should be passed inside an XRD. ·
[Paul]
On this call, I think a lot of people would support that. So you have a good
chance of prevailing there. ·
[John]
The nice thing about XRD is you can pass back an EPR and a portable contact to
an RP. ·
[Drummond]
I agree with John. The point of XRD is to be the one discovery format that
binds them all. ·
[Paul
] I agree we should scrape it , we shouldn’t use EPR’s natively. ·
[John]
Is the subject of the XRD the UDI? ·
[Drummond]
Yes. ·
[John]
Then you are always passing the XRD.. ·
[Markus]
I Don’t think it is a good idea to put an EPR in an xid. I would be
happier with just considering an EPR to be another kind of UDI, I think that
fits better in the overall data model. One of the most important concepts is
an entity relationship which contains a UDI. An r-card is just an application
of that data model ·
[Paul]
I agree with you. ·
[Drummond]The
devil’s advocate would say that the subject of the XRD is that entity
relation. It is a matter of how you are going to package the information. The
penalty of making it an XRD for everything is that you need to process that
even if you’ve just stuck in a UDI. ·
[Paul]
The foundation is .. ·
[John]
If you want to make the XRD a separate claim,,, most RP’s will want to
get other things with RESTful tokens…. ·
[Drummond]
That would suggest the possibility that there is a UDI claim and an XRD claim.
Don’t overload them. ·
[John/Markus]
You could use a dynamic UDI claim and the RP could pass in a parameter that
tells the STS in which format you want the USI. ·
[John]
That also works, that would be nicer than having three different claims types.
·
[Markus]
We would have to define… ·
[Drummond]
The dynamic claim ·
[John]
That is the part of the spec that doesn’t exist. ·
[Paul]
I envision Axels proposal ·
[John]
It is not going to be part of the IMI spec. It breaks WS-Fed. ·
…….. ·
[John]
Changing the claim URI has a whole bunch of consequences.. ·
[John]
Having structured claims requests and replies is best. ·
[Paul]
We have people who need to get on with it. Waiting a couple of years
isn’t going to work. John if you can advise us of a way that is more
likely to be closer to the eventual standard…. ·
[John]
I will work on documenting what I’ve been discussing. ·
[John]
What we are missing in the object tag is a pointer to the…. 5.
[Paul] Observations on Higgins from across the pond ·
[Mary]
The last agenda topic is Paul’s feedback from his recent trip to England ·
[Paul]
As you get further away from America and Higgins, I was observing their
perceptions of Higgins. It was sobering. One researcher fired up DigitalME and
looked at the card history, and it wasn’t there. He said that all there
is, is CardSpace. ·
[Paul]
The perception is that Higgins and ICF were actually funded by Microsoft. ·
[Paul]
Lastly even the packaged DigitalME is something only an administrator would
love. My take away is we can’t work hard enough and fast enough to make
Higgins end user consumable. We can’t move fast enough to improve the
Higgins project in all the ways we’ve talked about. People are taking the
temperature of the entire IC ecosystem. The entire world and what everyone
knows about CardSpace is being colored by Higgins. ·
[Drummond] ·
[Paul]
I came back realizing that even though Higgins isn’t a project we are
trying to attract end users to, it is important as every researcher is an end
user. Researchers use Higgins as a litmus test to see if the card ecosystem is
real. The answer is that the info card ecosystem isn’t ready for prime
time as it doesn’t have multiple implementations that are commercial
grade. From a polish point of view CardSpace looks real, and the Higgins stuff
looks not real. The consequences are very bad for everyone… ·
[Mary]
Did they try the Azigo selector or just DigitalME? ·
[Paul]
Just DigitalME. ·
[Andy]
Can have an agenda item for this next week? ·
[Mary]
Yes. ·
[John]
I was on a Concordia call conversation Scott Cantor and I have been looking at
ways to extend the IMI to support the web proxy selector… ·
[Paul]
Great. ·
[John]
We have a theory on that that requires very little change at the RP end. ·
[Paul]
We should talk about this next week too. ·
[Mary]
Yes. ·
[Paul]
We are out of time. Bye.
|