Comments on: Let’s Make Some Capabilities!!! http://eternallyoptimistic.com/2008/01/14/lets-make-some-capabilities/ Wed, 21 Apr 2010 14:34:25 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Pamela http://eternallyoptimistic.com/2008/01/14/lets-make-some-capabilities/comment-page-1/#comment-327 Pamela Wed, 16 Jan 2008 05:12:40 +0000 http://eternaloptimist.wordpress.com/2008/01/14/lets-make-some-capabilities/#comment-327 I have use cases for all of the capabilities Eric - I didn't include them because they tended to get repetitive, but I certainly can if you are interested. The reason why at I as an RP might want these particular capabilities available to me prior to the invocation of the protocols, is so that I can reduce the number of failed card transactions I trigger. If my RP uses an RP/STS, and I see that the user's selector advertisement is "isip:v1.0 -rpsts", I don't have to send the user on a fool's errand, I can give them an actionable message. The use case is basically the same for all of the capabilities I've listed here (noting that explicit lack of support is by far a better indicator than absence of explicit presence of support). I realize that there will be other uses for these strings, but this is the type of use case that has inspired my first attempt. Hope that helps, Pamela I have use cases for all of the capabilities Eric – I didn’t include them because they tended to get repetitive, but I certainly can if you are interested. The reason why at I as an RP might want these particular capabilities available to me prior to the invocation of the protocols, is so that I can reduce the number of failed card transactions I trigger. If my RP uses an RP/STS, and I see that the user’s selector advertisement is “isip:v1.0 -rpsts”, I don’t have to send the user on a fool’s errand, I can give them an actionable message. The use case is basically the same for all of the capabilities I’ve listed here (noting that explicit lack of support is by far a better indicator than absence of explicit presence of support). I realize that there will be other uses for these strings, but this is the type of use case that has inspired my first attempt.

Hope that helps,

Pamela

]]> By: Eric Norman http://eternallyoptimistic.com/2008/01/14/lets-make-some-capabilities/comment-page-1/#comment-326 Eric Norman Wed, 16 Jan 2008 04:27:32 +0000 http://eternaloptimist.wordpress.com/2008/01/14/lets-make-some-capabilities/#comment-326 How about starting with some use cases? How about following that up with some requirements? Why is is better to handle some of these in an "advertisement string" instead of with a later version of the information card protocols (if it can't be handled with current protocols)? The third and fourth seem especially screwey. If an identity selector can't do both, then it can't claim that it does information cards. The last time I checked, doing only one is not an option for identity selectors. I do like your response to Mike's suggestion. I wonder how many other proposed capabilities this argument would apply to. How about starting with some use cases?

How about following that up with some requirements?

Why is is better to handle some of these in an “advertisement string” instead of with a later version of the information card protocols (if it can’t be handled with current protocols)?

The third and fourth seem especially screwey. If an identity selector can’t do both, then it can’t claim that it does information cards. The last time I checked, doing only one is not an option for identity selectors.

I do like your response to Mike’s suggestion. I wonder how many other proposed capabilities this argument would apply to.

]]> By: Pamela http://eternallyoptimistic.com/2008/01/14/lets-make-some-capabilities/comment-page-1/#comment-325 Pamela Wed, 16 Jan 2008 03:49:56 +0000 http://eternaloptimist.wordpress.com/2008/01/14/lets-make-some-capabilities/#comment-325 I actually had that in there, but took it out before I posted it :) I figured that if the RP knows absolutely for sure that they have to have a certain backing for a card, they must know the issuer too - and if that's the case, why not just require the issuer... I actually had that in there, but took it out before I posted it :) I figured that if the RP knows absolutely for sure that they have to have a certain backing for a card, they must know the issuer too – and if that’s the case, why not just require the issuer…

]]> By: selfissued http://eternallyoptimistic.com/2008/01/14/lets-make-some-capabilities/comment-page-1/#comment-324 selfissued Wed, 16 Jan 2008 03:36:59 +0000 http://eternaloptimist.wordpress.com/2008/01/14/lets-make-some-capabilities/#comment-324 Great work Pamela! One possible refinement that might be used in practice is to allow Identity Selectors to declare that they do or don't support particular kinds of managed card authentication methods. I could imagine capabilities like these: managedcard:kerberos managedcard:x.509 managedcard:password managedcard:personal that together comprise your proposed managedcard identifier. Would that make managedcard a subgroup? Do we want nested groups? Great work Pamela!

One possible refinement that might be used in practice is to allow Identity Selectors to declare that they do or don’t support particular kinds of managed card authentication methods.

I could imagine capabilities like these:
managedcard:kerberos
managedcard:x.509
managedcard:password
managedcard:personal
that together comprise your proposed managedcard identifier.

Would that make managedcard a subgroup? Do we want nested groups?

]]>