[OpenID] Extensions - required and optional attributes

[Peter Williams]

Reason like the ISO committee who defined the X.509 v3 extensibility
model.

(a) ISO said - here is an ISO 8824 notational macro for defining
extension types for use in X.509 certs extension fields. And, here are
some uses of it (that had awful (NSA/DND) semantics that largely
confused the world of civilian applications, causing them to be ignored
or quickly profiled). Off you go, said ISO. Define your worlds....

This is OpendID 2.0 extensibility model.

(b) IETF PKIX group came along and defined a particular extension schema
using those macros, in some RFC I have not read in years.

This is SREG 1.1

(c) For a very short while, VeriSign had a formal meta-model for
communicating hierarchically-named schemas of X.509 extensions. (I stole
the abstract syntaxes used for almost the same purpose in X.501 when
constraining type hierarchies, and put them in the X.509 world)

This is a custom "vendor-specific" or "sub-community-specific" OpenID
2.0 extension, that schematizes extensions its hierarchy of extensions
classes. Its unrelated to SREG1.1.

This is what I did with my open suggestion yesterday, leveraging semweb
as the formal mechanism for expressing the schemas specifying lots of
extensions - relying on the various theories making up W3C's RDF
semantics.





> I'm finding myself confused by my own code at the moment, which
> probably
> means that I'm confused about the problem I'm trying to solve. But it
> does feel as if things would be clearer if there were some additional
> constraints on how an extension is to be used. So is there perhaps a
> reason why the "required" and "optional" parameters were delegated to
> the SReg spec, and not included in the core protocol?
> 
> --
> Jack Cleaver.
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general