[WG-UMA] New design principle/requirement around digital signatures?

[Eve Maler]

Since we've got a lot of folks who have joined the group since we last looked at the Requirements doc together, here's a little context/preamble about this doc:

http://kantarainitiative.org/confluence/display/uma/UMA+Requirements

We have allowed our requirements and design principles to be "emergent". We started out with bootstrap sets of them that came from our charter, but we have subsequently captured them only when it seems we have a shared assumption (hallucination?) that's strong and focused enough to record.

In today's call, it was clear that we find a lot of value in leveraging digital signatures as the methods for using them become more unambiguous, interoperable, and applicable to our use cases. With JWT getting more developed, we can make use of our DP5 around "modularity", by citing an external spec and only profiling it as necessary.

Since we have DPs and Rs around simplicity, adoption, sequestering complexity in the AM, avoiding new crypto burdens, etc., we may have gone a bit overboard, appearing to be wholly in the "anti-cryptarian" sect. In fact, we know we are interested in solving use cases that involve strong needs for security and privacy (hData being only one) and -- in the fullness of time -- trusted claims in general. Lots of use cases involving higher levels of assurance (in the lowercase, informal sense) do rely on stronger authentication, and JWT may ride to the rescue for these.

Proposal:

Since a DP is a general statement of goals and a requirement is something for which we can measure judge "conformance", I think this wants to be a DP. I propose the following as a strawman:

Title: Digital signatures

Principle: Don't preclude strong authentication through digital signatures, and leverage and adopt signatures as options if a reasonable measure of interoperability can be achieved.

Explanation/commentary: We see opportunities to leverage JWT that didn't exist when the group was first launched, and we have more overall experience with judging what is "reasonable" vs. "undue" crypto burdens now (see DP8, "Cryptography"). This principle mitigates the potentially heavy-handed effects of DP1 ("Simple") and DP10 ("Complexity") in forcing bearer tokens as a universal solution. Finally, this principle is consistent with DP11 ("Authentication") if we leverage an external spec for digital signatures and avoid defining a whole new one. This was discussed on 2011-01-27 [and other dates, TBS].

Comments? If we get consensus on this wording or a revision by next week, let's go ahead and do a vote on it.

Eve

Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

[Susan Morrow Avoco Secure]

I vote for this, it's wide enough a scope to cover most scenarios

Sent from my iPad

[Christian Scholz]

Hi!

As we are discussing this right now, here my thoughts

>> Proposal:
>>
>> Since a DP is a general statement of goals and a requirement is something for which we can measure judge "conformance", I think this wants to be a DP.  I propose the following as a strawman:
>>
>> Title: Digital signatures
>>
>> Principle: Don't preclude strong authentication through digital signatures, and leverage and adopt signatures as options if a reasonable measure of interoperability can be achieved.

Our current explanation:

Avoid adding crypto requirements beyond what existing web app
implementations do today.

And I think this is the core principle actually. What is good for
"ordinary web programmers" it will be good for us. The wording above
also sounds like trying to "answer" our existing principle as nothing
actually precludes crypto otherwise (if it's simple).

So I would do something along the line "Use only cryptographic methods
being used today on the web". So if JWT works for people then we can
use it. Enterprise use cases with maybe legacy systems can still use
different means.

>>
>> Explanation/commentary: We see opportunities to leverage JWT that didn't exist when the group was first launched, and we have more overall experience with judging what is "reasonable" vs. "undue" crypto burdens now (see DP8, "Cryptography").  This principle mitigates the potentially heavy-handed effects of DP1 ("Simple") and DP10 ("Complexity") in forcing bearer tokens as a universal solution.  Finally, this principle is consistent with DP11 ("Authentication") if we leverage an external spec for digital signatures and avoid defining a whole new one.  This was discussed on 2011-01-27 [and other dates, TBS].

This again sounds like an answer to the existing DP so I would see
this as an explanation of the change, not of the actual DP. Maybe it
can even stay the same.

cheers,

Christian

--
Christian Scholz, COM.lounge GmbH, tel. +49 241 400 730 0, http://comlounge.net
Blog: http://mrtopf.de/blog, Twitter: http://twitter.com/mrtopf

Podcasts:
Der OpenWeb-Podcast (http://openwebpodcast.de)
Data Without Borders (http://datawithoutborders.net)
Politisches: http://politfunk.de/

[Thomas Hardjono]

> Title: Digital signatures
>
> Principle: Don't preclude strong authentication through digital
> signatures, and leverage and adopt signatures as options if a
> reasonable measure of interoperability can be achieved.

Would it be better to state the principle in the positive:

"Allow strong source-authentication and non-repudiation through
digital signatures......"

Also, does this mean DP8 needs to be modified as well? The word
"today" the explanation is a fleeting term :-)

/thomas/

________________________

[Salvatore D'Agostino]

"..use web and related standards for cryptography to enable strong
authentication, privacy, integrity checks and non-repudiation."

As a suggestion.

Sal