OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: [regrep] SAML support in ebXML Registry: By Ed Buchinski et. al]


Everyone, on Friday we discussed a question on ebXML-dev regarding CPP. 
I have sent a followup note to Ed Buchinski and Farrukh Najmi to 
investigate if these new possible Reg/Rep functions may assist in the 
CPP question posed by Damian Rzepczyk (Damian.Rzepczyk@comarch.pl) [See 
(1) to jog your memory and mine].  I agree with Dale's response about 
storing the CPP with the signature. Thanks.

==========================================================================================

> Najmi: TC Members,
> Per my action item from last TC meeting I have been digging deeper 
> into the issue of SAML support for ebXML Registry.
> Attached is a paper by Ed Buchinski et. al from the Canadian 
> Government on the subject. Please share your thoughts
> on this thread. I am particularly interested in questions or thoughts 
> you may have on specific changes we may have to make
> in our 3.0 specs in order to support SAML.
>
> One question raised thus far in last TC meeting was whether SAML 1.1 
> support by ebXML Registry should be required or optional.
> Your thoughts on that issue would be a good starting point.
>
> Thanks. 

==========================================================================================
(1) From Damian.Rzepczyk@comarch.pl to ebxml-dev list:
So I would ask you some questions.  One party of this project is GUI WWW 
interface. We would like to build interface which allow user to enter 
and edit
CPP in the web browser (for example MS Internet Explorer).........The 
next question is how store CPP in SQL database. There are 2 solutions:
1. Store whole CPP XML file in one column in table.
2. Divide the CPP on tags, and store CPP in few tables. For example 
divide CPP on PartyInfo, SimplePart, Packaking, Signature. Then divide 
PartyInfo, divide SimplePart, and so on.
Could you tell me which solutions is better?
The 1 is very easy for implement. But later is more dificult to edit 
that CPP in web browser. The searching is more difficult, too. For 
example how to find CPP which have tp:partyName == "Acme"? For all CPPs 
stored in repository, parse CPP and check if tag tp:partyName == "Acme"?
The 2 is very complex. But later is easier to do editor in web browser.
And searching is easier (SELECT * FROM PartyInfo WHERE partyName = 
"ACME" ).
<<<One more issue. What if the one client digitaly sign CPP, and put 
signature to CPP XML in tag tp:Signature. Then client put CPP in our 
repository. We divide it and put all values to tables. When second 
client want to download the first client CPP, we will get values from 
tables, and put to XML. But then the signature won't meet the CPP XML 
file :(So if I think properly, we must not divide signed CPP? If we get 
signded CPP we must store it in one field in table? >>>
=========================================================================

--- Begin Message ---

TC Members,

Per my action item from last TC meeting I have been digging deeper into 
the issue of SAML support for ebXML Registry.
Attached is a paper by Ed Buchinski et. al from the Canadian Government 
on the subject. Please share your thoughts
on this thread. I am particularly interested in questions or thoughts 
you may have on specific changes we may have to make
in our 3.0 specs in order to support SAML.

One question raised thus far in last TC meeting was whether SAML 1.1 
support by ebXML Registry should be required or optional.
Your thoughts on that issue would be a good starting point.

Thanks.

-- 
Regards,
Farrukh

SAMLSupportInebXMLRegistry.pdf

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
--- End Message ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]